From 88ea40b8836b438e1649fa5c9661daae7191dd39 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 16 Jan 2018 16:35:44 -0500 Subject: [PATCH 0001/2516] add `mdbook init` --- src/doc/rustc-dev-guide/.gitignore | 1 + src/doc/rustc-dev-guide/src/SUMMARY.md | 3 +++ src/doc/rustc-dev-guide/src/chapter_1.md | 1 + 3 files changed, 5 insertions(+) create mode 100644 src/doc/rustc-dev-guide/.gitignore create mode 100644 src/doc/rustc-dev-guide/src/SUMMARY.md create mode 100644 src/doc/rustc-dev-guide/src/chapter_1.md diff --git a/src/doc/rustc-dev-guide/.gitignore b/src/doc/rustc-dev-guide/.gitignore new file mode 100644 index 0000000000000..5a0bf0317d75c --- /dev/null +++ b/src/doc/rustc-dev-guide/.gitignore @@ -0,0 +1 @@ +/book diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md new file mode 100644 index 0000000000000..7390c82896e56 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/SUMMARY.md @@ -0,0 +1,3 @@ +# Summary + +- [Chapter 1](./chapter_1.md) diff --git a/src/doc/rustc-dev-guide/src/chapter_1.md b/src/doc/rustc-dev-guide/src/chapter_1.md new file mode 100644 index 0000000000000..b743fda354692 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/chapter_1.md @@ -0,0 +1 @@ +# Chapter 1 From dfee0655aa93bbe7abdc2806f43bd67b6241c236 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 16 Jan 2018 16:36:21 -0500 Subject: [PATCH 0002/2516] add code-of-conduct, licensing material, and a README --- src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md | 38 ++++ src/doc/rustc-dev-guide/LICENSE-APACHE | 201 +++++++++++++++++++++ src/doc/rustc-dev-guide/LICENSE-MIT | 23 +++ src/doc/rustc-dev-guide/README.md | 3 + 4 files changed, 265 insertions(+) create mode 100644 src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md create mode 100644 src/doc/rustc-dev-guide/LICENSE-APACHE create mode 100644 src/doc/rustc-dev-guide/LICENSE-MIT create mode 100644 src/doc/rustc-dev-guide/README.md diff --git a/src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md b/src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md new file mode 100644 index 0000000000000..d42476bc4130d --- /dev/null +++ b/src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md @@ -0,0 +1,38 @@ +# 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/).* diff --git a/src/doc/rustc-dev-guide/LICENSE-APACHE b/src/doc/rustc-dev-guide/LICENSE-APACHE new file mode 100644 index 0000000000000..16fe87b06e802 --- /dev/null +++ b/src/doc/rustc-dev-guide/LICENSE-APACHE @@ -0,0 +1,201 @@ + Apache License + Version 2.0, January 2004 + http://www.apache.org/licenses/ + +TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + +1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the Work, but + excluding communication that is conspicuously marked or otherwise + designated in writing by the copyright owner as "Not a Contribution." + + "Contributor" shall mean Licensor and any individual or Legal Entity + on behalf of whom a Contribution has been received by Licensor and + subsequently incorporated within the Work. + +2. Grant of Copyright License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + copyright license to reproduce, prepare Derivative Works of, + publicly display, publicly perform, sublicense, and distribute the + Work and such Derivative Works in Source or Object form. + +3. Grant of Patent License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + (except as stated in this section) patent license to make, have made, + use, offer to sell, sell, import, and otherwise transfer the Work, + where such license applies only to those patent claims licensable + by such Contributor that are necessarily infringed by their + Contribution(s) alone or by combination of their Contribution(s) + with the Work to which such Contribution(s) was submitted. If You + institute patent litigation against any entity (including a + cross-claim or counterclaim in a lawsuit) alleging that the Work + or a Contribution incorporated within the Work constitutes direct + or contributory patent infringement, then any patent licenses + granted to You under this License for that Work shall terminate + as of the date such litigation is filed. + +4. Redistribution. You may reproduce and distribute copies of the + Work or Derivative Works thereof in any medium, with or without + modifications, and in Source or Object form, provided that You + meet the following conditions: + + (a) You must give any other recipients of the Work or + Derivative Works a copy of this License; and + + (b) You must cause any modified files to carry prominent notices + stating that You changed the files; and + + (c) You must retain, in the Source form of any Derivative Works + that You distribute, all copyright, patent, trademark, and + attribution notices from the Source form of the Work, + excluding those notices that do not pertain to any part of + the Derivative Works; and + + (d) If the Work includes a "NOTICE" text file as part of its + distribution, then any Derivative Works that You distribute must + include a readable copy of the attribution notices contained + within such NOTICE file, excluding those notices that do not + pertain to any part of the Derivative Works, in at least one + of the following places: within a NOTICE text file distributed + as part of the Derivative Works; within the Source form or + documentation, if provided along with the Derivative Works; or, + within a display generated by the Derivative Works, if and + wherever such third-party notices normally appear. The contents + of the NOTICE file are for informational purposes only and + do not modify the License. You may add Your own attribution + notices within Derivative Works that You distribute, alongside + or as an addendum to the NOTICE text from the Work, provided + that such additional attribution notices cannot be construed + as modifying the License. + + You may add Your own copyright statement to Your modifications and + may provide additional or different license terms and conditions + for use, reproduction, or distribution of Your modifications, or + for any such Derivative Works as a whole, provided Your use, + reproduction, and distribution of the Work otherwise complies with + the conditions stated in this License. + +5. Submission of Contributions. Unless You explicitly state otherwise, + any Contribution intentionally submitted for inclusion in the Work + by You to the Licensor shall be under the terms and conditions of + this License, without any additional terms or conditions. + Notwithstanding the above, nothing herein shall supersede or modify + the terms of any separate license agreement you may have executed + with Licensor regarding such Contributions. + +6. Trademarks. This License does not grant permission to use the trade + names, trademarks, service marks, or product names of the Licensor, + except as required for reasonable and customary use in describing the + origin of the Work and reproducing the content of the NOTICE file. + +7. Disclaimer of Warranty. Unless required by applicable law or + agreed to in writing, Licensor provides the Work (and each + Contributor provides its Contributions) on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + implied, including, without limitation, any warranties or conditions + of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A + PARTICULAR PURPOSE. You are solely responsible for determining the + appropriateness of using or redistributing the Work and assume any + risks associated with Your exercise of permissions under this License. + +8. Limitation of Liability. In no event and under no legal theory, + whether in tort (including negligence), contract, or otherwise, + unless required by applicable law (such as deliberate and grossly + negligent acts) or agreed to in writing, shall any Contributor be + liable to You for damages, including any direct, indirect, special, + incidental, or consequential damages of any character arising as a + result of this License or out of the use or inability to use the + Work (including but not limited to damages for loss of goodwill, + work stoppage, computer failure or malfunction, or any and all + other commercial damages or losses), even if such Contributor + has been advised of the possibility of such damages. + +9. Accepting Warranty or Additional Liability. While redistributing + the Work or Derivative Works thereof, You may choose to offer, + and charge a fee for, acceptance of support, warranty, indemnity, + or other liability obligations and/or rights consistent with this + License. However, in accepting such obligations, You may act only + on Your own behalf and on Your sole responsibility, not on behalf + of any other Contributor, and only if You agree to indemnify, + defend, and hold each Contributor harmless for any liability + incurred by, or claims asserted against, such Contributor by reason + of your accepting any such warranty or additional liability. + +END OF TERMS AND CONDITIONS + +APPENDIX: How to apply the Apache License to your work. + + To apply the Apache License to your work, attach the following + boilerplate notice, with the fields enclosed by brackets "[]" + replaced with your own identifying information. (Don't include + the brackets!) The text should be enclosed in the appropriate + comment syntax for the file format. We also recommend that a + file or class name and description of purpose be included on the + same "printed page" as the copyright notice for easier + identification within third-party archives. + +Copyright [yyyy] [name of copyright owner] + +Licensed under the Apache License, Version 2.0 (the "License"); +you may not use this file except in compliance with the License. +You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an "AS IS" BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. diff --git a/src/doc/rustc-dev-guide/LICENSE-MIT b/src/doc/rustc-dev-guide/LICENSE-MIT new file mode 100644 index 0000000000000..31aa79387f27e --- /dev/null +++ b/src/doc/rustc-dev-guide/LICENSE-MIT @@ -0,0 +1,23 @@ +Permission is hereby granted, free of charge, to any +person obtaining a copy of this software and associated +documentation files (the "Software"), to deal in the +Software without restriction, including without +limitation the rights to use, copy, modify, merge, +publish, distribute, sublicense, and/or sell copies of +the Software, and to permit persons to whom the Software +is furnished to do so, subject to the following +conditions: + +The above copyright notice and this permission notice +shall be included in all copies or substantial portions +of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF +ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED +TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A +PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT +SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY +CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION +OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR +IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md new file mode 100644 index 0000000000000..d41418f2f4e01 --- /dev/null +++ b/src/doc/rustc-dev-guide/README.md @@ -0,0 +1,3 @@ +An attempt to docuemnt how the compiler works. The intention is to +bootstrap this "in repo" and eventually move the text over into the +main rustc repo. From e049167364462e3de46d87c50e2b145add4412c2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 16 Jan 2018 17:35:19 -0500 Subject: [PATCH 0003/2516] add outline and chapters --- src/doc/rustc-dev-guide/.gitignore | 2 +- src/doc/rustc-dev-guide/book.toml | 5 +++++ src/doc/rustc-dev-guide/src/SUMMARY.md | 3 --- src/doc/rustc-dev-guide/src/chapter_1.md | 1 - src/doc/rustc-dev-guide/src/src/SUMMARY.md | 19 +++++++++++++++++++ .../src/src/chap-010-how-to-build-and-run.md | 1 + .../src/src/chap-020-running-tests.md | 1 + .../src/src/chap-030-walkthrough.md | 1 + .../src/src/chap-040-compiler-conventions.md | 1 + .../src/src/chap-050-the-parser.md | 1 + .../src/src/chap-060-macro-expansion.md | 1 + .../src/src/chap-070-name-resolution.md | 1 + .../src/src/chap-080-hir-lowering.md | 1 + .../rustc-dev-guide/src/src/chap-090-ty.md | 1 + .../src/src/chap-100-type-inference.md | 1 + .../src/src/chap-110-trait-resolution.md | 1 + .../src/src/chap-120-type-checking.md | 1 + .../src/src/chap-130-mir-construction.md | 1 + .../src/src/chap-140-mir-borrowck.md | 1 + .../src/src/chap-150-mir-optimizations.md | 1 + .../rustc-dev-guide/src/src/chap-160-trans.md | 1 + 21 files changed, 41 insertions(+), 5 deletions(-) create mode 100644 src/doc/rustc-dev-guide/book.toml delete mode 100644 src/doc/rustc-dev-guide/src/SUMMARY.md delete mode 100644 src/doc/rustc-dev-guide/src/chapter_1.md create mode 100644 src/doc/rustc-dev-guide/src/src/SUMMARY.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-010-how-to-build-and-run.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-020-running-tests.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-030-walkthrough.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-040-compiler-conventions.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-050-the-parser.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-070-name-resolution.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-080-hir-lowering.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-090-ty.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-100-type-inference.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-110-trait-resolution.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-120-type-checking.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-130-mir-construction.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-140-mir-borrowck.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-150-mir-optimizations.md create mode 100644 src/doc/rustc-dev-guide/src/src/chap-160-trans.md diff --git a/src/doc/rustc-dev-guide/.gitignore b/src/doc/rustc-dev-guide/.gitignore index 5a0bf0317d75c..7585238efedfc 100644 --- a/src/doc/rustc-dev-guide/.gitignore +++ b/src/doc/rustc-dev-guide/.gitignore @@ -1 +1 @@ -/book +book diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml new file mode 100644 index 0000000000000..485a12ca3bbda --- /dev/null +++ b/src/doc/rustc-dev-guide/book.toml @@ -0,0 +1,5 @@ +[book] +title = "Guide to Rustc Development" +author = "Rustc developers" +description = "A guide to developing rustc " + diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md deleted file mode 100644 index 7390c82896e56..0000000000000 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ /dev/null @@ -1,3 +0,0 @@ -# Summary - -- [Chapter 1](./chapter_1.md) diff --git a/src/doc/rustc-dev-guide/src/chapter_1.md b/src/doc/rustc-dev-guide/src/chapter_1.md deleted file mode 100644 index b743fda354692..0000000000000 --- a/src/doc/rustc-dev-guide/src/chapter_1.md +++ /dev/null @@ -1 +0,0 @@ -# Chapter 1 diff --git a/src/doc/rustc-dev-guide/src/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/src/SUMMARY.md new file mode 100644 index 0000000000000..134014963cb19 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/SUMMARY.md @@ -0,0 +1,19 @@ +# Summary + +- [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) +- [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) + diff --git a/src/doc/rustc-dev-guide/src/src/chap-010-how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/src/chap-010-how-to-build-and-run.md new file mode 100644 index 0000000000000..505836094d10f --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-010-how-to-build-and-run.md @@ -0,0 +1 @@ +# How to build the compiler and run what you built diff --git a/src/doc/rustc-dev-guide/src/src/chap-020-running-tests.md b/src/doc/rustc-dev-guide/src/src/chap-020-running-tests.md new file mode 100644 index 0000000000000..02c9de84067fa --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-020-running-tests.md @@ -0,0 +1 @@ +# Using the compiler testing framework diff --git a/src/doc/rustc-dev-guide/src/src/chap-030-walkthrough.md b/src/doc/rustc-dev-guide/src/src/chap-030-walkthrough.md new file mode 100644 index 0000000000000..ab158177a420d --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-030-walkthrough.md @@ -0,0 +1 @@ +# Walkthrough: a typical contribution diff --git a/src/doc/rustc-dev-guide/src/src/chap-040-compiler-conventions.md b/src/doc/rustc-dev-guide/src/src/chap-040-compiler-conventions.md new file mode 100644 index 0000000000000..314221fa0e577 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-040-compiler-conventions.md @@ -0,0 +1 @@ +# Conventions used in the compiler diff --git a/src/doc/rustc-dev-guide/src/src/chap-050-the-parser.md b/src/doc/rustc-dev-guide/src/src/chap-050-the-parser.md new file mode 100644 index 0000000000000..ab756895ae6a9 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-050-the-parser.md @@ -0,0 +1 @@ +# The parser diff --git a/src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md b/src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md new file mode 100644 index 0000000000000..12b95cb6cb074 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md @@ -0,0 +1 @@ +# Macro expansion diff --git a/src/doc/rustc-dev-guide/src/src/chap-070-name-resolution.md b/src/doc/rustc-dev-guide/src/src/chap-070-name-resolution.md new file mode 100644 index 0000000000000..487a31d2c5297 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-070-name-resolution.md @@ -0,0 +1 @@ +# Name resolution diff --git a/src/doc/rustc-dev-guide/src/src/chap-080-hir-lowering.md b/src/doc/rustc-dev-guide/src/src/chap-080-hir-lowering.md new file mode 100644 index 0000000000000..b2b6a7cdf8f36 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-080-hir-lowering.md @@ -0,0 +1 @@ +# HIR lowering diff --git a/src/doc/rustc-dev-guide/src/src/chap-090-ty.md b/src/doc/rustc-dev-guide/src/src/chap-090-ty.md new file mode 100644 index 0000000000000..1762ce037fa7c --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-090-ty.md @@ -0,0 +1 @@ +# Representing types (`ty` module in depth) diff --git a/src/doc/rustc-dev-guide/src/src/chap-100-type-inference.md b/src/doc/rustc-dev-guide/src/src/chap-100-type-inference.md new file mode 100644 index 0000000000000..0fc99252ab73a --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-100-type-inference.md @@ -0,0 +1 @@ +# Type inference diff --git a/src/doc/rustc-dev-guide/src/src/chap-110-trait-resolution.md b/src/doc/rustc-dev-guide/src/src/chap-110-trait-resolution.md new file mode 100644 index 0000000000000..dd16aac62b4e4 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-110-trait-resolution.md @@ -0,0 +1 @@ +# Trait resolution diff --git a/src/doc/rustc-dev-guide/src/src/chap-120-type-checking.md b/src/doc/rustc-dev-guide/src/src/chap-120-type-checking.md new file mode 100644 index 0000000000000..c559c1283600f --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-120-type-checking.md @@ -0,0 +1 @@ +# Type checking diff --git a/src/doc/rustc-dev-guide/src/src/chap-130-mir-construction.md b/src/doc/rustc-dev-guide/src/src/chap-130-mir-construction.md new file mode 100644 index 0000000000000..898fcd529ed67 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-130-mir-construction.md @@ -0,0 +1 @@ +# MIR construction diff --git a/src/doc/rustc-dev-guide/src/src/chap-140-mir-borrowck.md b/src/doc/rustc-dev-guide/src/src/chap-140-mir-borrowck.md new file mode 100644 index 0000000000000..55bc9fc982af2 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-140-mir-borrowck.md @@ -0,0 +1 @@ +# MIR borrowck diff --git a/src/doc/rustc-dev-guide/src/src/chap-150-mir-optimizations.md b/src/doc/rustc-dev-guide/src/src/chap-150-mir-optimizations.md new file mode 100644 index 0000000000000..ddafa0c99c394 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-150-mir-optimizations.md @@ -0,0 +1 @@ +# MIR optimizations diff --git a/src/doc/rustc-dev-guide/src/src/chap-160-trans.md b/src/doc/rustc-dev-guide/src/src/chap-160-trans.md new file mode 100644 index 0000000000000..7092b7a0baf06 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/chap-160-trans.md @@ -0,0 +1 @@ +# trans: generating LLVM IR From 5833d7447da5792a39b480d06f3715bb9e5efb4a Mon Sep 17 00:00:00 2001 From: Jonathan Turner Date: Wed, 17 Jan 2018 13:13:13 +1300 Subject: [PATCH 0004/2516] Update README.md --- src/doc/rustc-dev-guide/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index d41418f2f4e01..b8929c1e3f926 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 c08d4c0bfd488473fed766f72552ad565f468f15 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 16 Jan 2018 18:43:10 -0600 Subject: [PATCH 0005/2516] Add glossary --- src/doc/rustc-dev-guide/src/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/src/glossary.md | 31 +++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/src/src/glossary.md diff --git a/src/doc/rustc-dev-guide/src/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/src/SUMMARY.md index 134014963cb19..21c87188555bc 100644 --- a/src/doc/rustc-dev-guide/src/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/src/src/SUMMARY.md @@ -16,4 +16,4 @@ - [MIR borrowck](./chap-140-mir-borrowck.md) - [MIR optimizations](./chap-150-mir-optimizations.md) - [trans: generating LLVM IR](./chap-160-trans.md) - +- [Glossary](./glossary.md) diff --git a/src/doc/rustc-dev-guide/src/src/glossary.md b/src/doc/rustc-dev-guide/src/src/glossary.md new file mode 100644 index 0000000000000..b66e17ea3c18c --- /dev/null +++ b/src/doc/rustc-dev-guide/src/src/glossary.md @@ -0,0 +1,31 @@ +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. +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`. +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`). +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`. +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`. +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`). +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`). From 6a76becdbf8d9ef23c79b3450ef4cf7c616402cb Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 17 Jan 2018 12:30:45 +0800 Subject: [PATCH 0006/2516] Created a couple basic CI scripts --- src/doc/rustc-dev-guide/.travis.yml | 17 +++++++++++++++++ src/doc/rustc-dev-guide/ci/github_pages.sh | 10 ++++++++++ src/doc/rustc-dev-guide/ci/install.sh | 6 ++++++ 3 files changed, 33 insertions(+) create mode 100644 src/doc/rustc-dev-guide/.travis.yml create mode 100644 src/doc/rustc-dev-guide/ci/github_pages.sh create mode 100644 src/doc/rustc-dev-guide/ci/install.sh diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml new file mode 100644 index 0000000000000..e1fcfa9bf9ec9 --- /dev/null +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/github_pages.sh b/src/doc/rustc-dev-guide/ci/github_pages.sh new file mode 100644 index 0000000000000..603b280f98392 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh new file mode 100644 index 0000000000000..d9cb369e5488a --- /dev/null +++ b/src/doc/rustc-dev-guide/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 51aa31de21cda57abe0742d22f8881de4ef5d904 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 17 Jan 2018 09:19:24 -0500 Subject: [PATCH 0007/2516] improve the README --- src/doc/rustc-dev-guide/README.md | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index b8929c1e3f926..beb2507cd21ef 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 fb0e1b38c8d2073b85a7bd4409d4f88c8ec2225c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 17 Jan 2018 09:25:59 -0500 Subject: [PATCH 0008/2516] remove `src/src` directory that somehow got created --- src/doc/rustc-dev-guide/src/{src => }/SUMMARY.md | 0 .../src/{src => }/chap-010-how-to-build-and-run.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-020-running-tests.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-030-walkthrough.md | 0 .../src/{src => }/chap-040-compiler-conventions.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-050-the-parser.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-060-macro-expansion.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-070-name-resolution.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-080-hir-lowering.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-090-ty.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-100-type-inference.md | 0 .../rustc-dev-guide/src/{src => }/chap-110-trait-resolution.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-120-type-checking.md | 0 .../rustc-dev-guide/src/{src => }/chap-130-mir-construction.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-140-mir-borrowck.md | 0 .../rustc-dev-guide/src/{src => }/chap-150-mir-optimizations.md | 0 src/doc/rustc-dev-guide/src/{src => }/chap-160-trans.md | 0 src/doc/rustc-dev-guide/src/{src => }/glossary.md | 0 18 files changed, 0 insertions(+), 0 deletions(-) rename src/doc/rustc-dev-guide/src/{src => }/SUMMARY.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-010-how-to-build-and-run.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-020-running-tests.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-030-walkthrough.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-040-compiler-conventions.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-050-the-parser.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-060-macro-expansion.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-070-name-resolution.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-080-hir-lowering.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-090-ty.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-100-type-inference.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-110-trait-resolution.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-120-type-checking.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-130-mir-construction.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-140-mir-borrowck.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-150-mir-optimizations.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/chap-160-trans.md (100%) rename src/doc/rustc-dev-guide/src/{src => }/glossary.md (100%) diff --git a/src/doc/rustc-dev-guide/src/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/SUMMARY.md rename to src/doc/rustc-dev-guide/src/SUMMARY.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-010-how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/chap-010-how-to-build-and-run.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-010-how-to-build-and-run.md rename to src/doc/rustc-dev-guide/src/chap-010-how-to-build-and-run.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-020-running-tests.md b/src/doc/rustc-dev-guide/src/chap-020-running-tests.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-020-running-tests.md rename to src/doc/rustc-dev-guide/src/chap-020-running-tests.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-030-walkthrough.md b/src/doc/rustc-dev-guide/src/chap-030-walkthrough.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-030-walkthrough.md rename to src/doc/rustc-dev-guide/src/chap-030-walkthrough.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-040-compiler-conventions.md b/src/doc/rustc-dev-guide/src/chap-040-compiler-conventions.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-040-compiler-conventions.md rename to src/doc/rustc-dev-guide/src/chap-040-compiler-conventions.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-050-the-parser.md b/src/doc/rustc-dev-guide/src/chap-050-the-parser.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-050-the-parser.md rename to src/doc/rustc-dev-guide/src/chap-050-the-parser.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md b/src/doc/rustc-dev-guide/src/chap-060-macro-expansion.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md rename to src/doc/rustc-dev-guide/src/chap-060-macro-expansion.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-070-name-resolution.md b/src/doc/rustc-dev-guide/src/chap-070-name-resolution.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-070-name-resolution.md rename to src/doc/rustc-dev-guide/src/chap-070-name-resolution.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-080-hir-lowering.md b/src/doc/rustc-dev-guide/src/chap-080-hir-lowering.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-080-hir-lowering.md rename to src/doc/rustc-dev-guide/src/chap-080-hir-lowering.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-090-ty.md b/src/doc/rustc-dev-guide/src/chap-090-ty.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-090-ty.md rename to src/doc/rustc-dev-guide/src/chap-090-ty.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-100-type-inference.md b/src/doc/rustc-dev-guide/src/chap-100-type-inference.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-100-type-inference.md rename to src/doc/rustc-dev-guide/src/chap-100-type-inference.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-110-trait-resolution.md b/src/doc/rustc-dev-guide/src/chap-110-trait-resolution.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-110-trait-resolution.md rename to src/doc/rustc-dev-guide/src/chap-110-trait-resolution.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-120-type-checking.md b/src/doc/rustc-dev-guide/src/chap-120-type-checking.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-120-type-checking.md rename to src/doc/rustc-dev-guide/src/chap-120-type-checking.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-130-mir-construction.md b/src/doc/rustc-dev-guide/src/chap-130-mir-construction.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-130-mir-construction.md rename to src/doc/rustc-dev-guide/src/chap-130-mir-construction.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-140-mir-borrowck.md b/src/doc/rustc-dev-guide/src/chap-140-mir-borrowck.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-140-mir-borrowck.md rename to src/doc/rustc-dev-guide/src/chap-140-mir-borrowck.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-150-mir-optimizations.md b/src/doc/rustc-dev-guide/src/chap-150-mir-optimizations.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-150-mir-optimizations.md rename to src/doc/rustc-dev-guide/src/chap-150-mir-optimizations.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-160-trans.md b/src/doc/rustc-dev-guide/src/chap-160-trans.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/chap-160-trans.md rename to src/doc/rustc-dev-guide/src/chap-160-trans.md diff --git a/src/doc/rustc-dev-guide/src/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md similarity index 100% rename from src/doc/rustc-dev-guide/src/src/glossary.md rename to src/doc/rustc-dev-guide/src/glossary.md From 0241b587623c0f91c82f0a03952b79159d98b84e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 17 Jan 2018 09:53:45 -0500 Subject: [PATCH 0009/2516] add link to gh-pages --- src/doc/rustc-dev-guide/README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index beb2507cd21ef..5ff51de2b7382 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 02d40b33f487de79111d2851d4cd1ffe6682226f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 06:38:33 -0500 Subject: [PATCH 0010/2516] add an "about this guide" section --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/chap-000-about-this-guide.md | 14 ++++++++++++++ 2 files changed, 15 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/chap-000-about-this-guide.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 21c87188555bc..30dde6fb978c4 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/chap-000-about-this-guide.md b/src/doc/rustc-dev-guide/src/chap-000-about-this-guide.md new file mode 100644 index 0000000000000..ea840177b55b4 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 36e0ed803867bab4d8fc05d921eae96cdeea0ae4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 06:38:40 -0500 Subject: [PATCH 0011/2516] replace "conventions" with "high-level overview" Also bring in material from the librustc README.md --- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/chap-040-compiler-conventions.md create mode 100644 src/doc/rustc-dev-guide/src/chap-040-high-level-overview.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 30dde6fb978c4..1c87e26cebfb5 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/chap-040-compiler-conventions.md b/src/doc/rustc-dev-guide/src/chap-040-compiler-conventions.md deleted file mode 100644 index 314221fa0e577..0000000000000 --- a/src/doc/rustc-dev-guide/src/chap-040-compiler-conventions.md +++ /dev/null @@ -1 +0,0 @@ -# Conventions used in the compiler diff --git a/src/doc/rustc-dev-guide/src/chap-040-high-level-overview.md b/src/doc/rustc-dev-guide/src/chap-040-high-level-overview.md new file mode 100644 index 0000000000000..b8d75bff69045 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 25e5ed9be5af1f34c5b66f32626ad602f0cf9f20 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 06:42:50 -0500 Subject: [PATCH 0012/2516] remove the `chap-NNN-` convention from file names I don't want those showing up in the URLs. --- src/doc/rustc-dev-guide/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 .../{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/doc/rustc-dev-guide/src/{chap-000-about-this-guide.md => about-this-guide.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-040-high-level-overview.md => high-level-overview.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-080-hir-lowering.md => hir-lowering.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-010-how-to-build-and-run.md => how-to-build-and-run.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-060-macro-expansion.md => macro-expansion.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-140-mir-borrowck.md => mir-borrowck.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-130-mir-construction.md => mir-construction.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-150-mir-optimizations.md => mir-optimizations.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-070-name-resolution.md => name-resolution.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-020-running-tests.md => running-tests.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-050-the-parser.md => the-parser.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-110-trait-resolution.md => trait-resolution.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-160-trans.md => trans.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-090-ty.md => ty.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-120-type-checking.md => type-checking.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-100-type-inference.md => type-inference.md} (100%) rename src/doc/rustc-dev-guide/src/{chap-030-walkthrough.md => walkthrough.md} (100%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 1c87e26cebfb5..b1dfa440d64f8 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/chap-000-about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-000-about-this-guide.md rename to src/doc/rustc-dev-guide/src/about-this-guide.md diff --git a/src/doc/rustc-dev-guide/src/chap-040-high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-040-high-level-overview.md rename to src/doc/rustc-dev-guide/src/high-level-overview.md diff --git a/src/doc/rustc-dev-guide/src/chap-080-hir-lowering.md b/src/doc/rustc-dev-guide/src/hir-lowering.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-080-hir-lowering.md rename to src/doc/rustc-dev-guide/src/hir-lowering.md diff --git a/src/doc/rustc-dev-guide/src/chap-010-how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-010-how-to-build-and-run.md rename to src/doc/rustc-dev-guide/src/how-to-build-and-run.md diff --git a/src/doc/rustc-dev-guide/src/chap-060-macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-060-macro-expansion.md rename to src/doc/rustc-dev-guide/src/macro-expansion.md diff --git a/src/doc/rustc-dev-guide/src/chap-140-mir-borrowck.md b/src/doc/rustc-dev-guide/src/mir-borrowck.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-140-mir-borrowck.md rename to src/doc/rustc-dev-guide/src/mir-borrowck.md diff --git a/src/doc/rustc-dev-guide/src/chap-130-mir-construction.md b/src/doc/rustc-dev-guide/src/mir-construction.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-130-mir-construction.md rename to src/doc/rustc-dev-guide/src/mir-construction.md diff --git a/src/doc/rustc-dev-guide/src/chap-150-mir-optimizations.md b/src/doc/rustc-dev-guide/src/mir-optimizations.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-150-mir-optimizations.md rename to src/doc/rustc-dev-guide/src/mir-optimizations.md diff --git a/src/doc/rustc-dev-guide/src/chap-070-name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-070-name-resolution.md rename to src/doc/rustc-dev-guide/src/name-resolution.md diff --git a/src/doc/rustc-dev-guide/src/chap-020-running-tests.md b/src/doc/rustc-dev-guide/src/running-tests.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-020-running-tests.md rename to src/doc/rustc-dev-guide/src/running-tests.md diff --git a/src/doc/rustc-dev-guide/src/chap-050-the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-050-the-parser.md rename to src/doc/rustc-dev-guide/src/the-parser.md diff --git a/src/doc/rustc-dev-guide/src/chap-110-trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-110-trait-resolution.md rename to src/doc/rustc-dev-guide/src/trait-resolution.md diff --git a/src/doc/rustc-dev-guide/src/chap-160-trans.md b/src/doc/rustc-dev-guide/src/trans.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-160-trans.md rename to src/doc/rustc-dev-guide/src/trans.md diff --git a/src/doc/rustc-dev-guide/src/chap-090-ty.md b/src/doc/rustc-dev-guide/src/ty.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-090-ty.md rename to src/doc/rustc-dev-guide/src/ty.md diff --git a/src/doc/rustc-dev-guide/src/chap-120-type-checking.md b/src/doc/rustc-dev-guide/src/type-checking.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-120-type-checking.md rename to src/doc/rustc-dev-guide/src/type-checking.md diff --git a/src/doc/rustc-dev-guide/src/chap-100-type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-100-type-inference.md rename to src/doc/rustc-dev-guide/src/type-inference.md diff --git a/src/doc/rustc-dev-guide/src/chap-030-walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md similarity index 100% rename from src/doc/rustc-dev-guide/src/chap-030-walkthrough.md rename to src/doc/rustc-dev-guide/src/walkthrough.md From c2ddcd463ba8fc059343c0f1fa7c6af6339c6d98 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 06:43:10 -0500 Subject: [PATCH 0013/2516] add in the trait resolution README from rustc --- .../rustc-dev-guide/src/trait-resolution.md | 484 ++++++++++++++++++ 1 file changed, 484 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index dd16aac62b4e4..58efbd05039e9 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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 79f9546ac5bfb2fcc91382a2f5c2e97bbfebb8ad Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 06:51:14 -0500 Subject: [PATCH 0014/2516] move over the `ty` README --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/ty.md | 166 ++++++++++++++++++++++++- 2 files changed, 166 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index b1dfa440d64f8..f8b1f1d6e0c1f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 1762ce037fa7c..8debb71c788e5 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 469b4e0072f8238a9ac8f7eb06d5e99335956b4d Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 07:28:19 -0500 Subject: [PATCH 0015/2516] invoke `cargo` to install mdbook --- src/doc/rustc-dev-guide/.travis.yml | 2 +- src/doc/rustc-dev-guide/ci/install.sh | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index e1fcfa9bf9ec9..5978c61d84548 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index d9cb369e5488a..dd96daf178fed 100644 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 444fa3a721f32159d6e9a13d5e2db841582d9cf1 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 14:48:35 -0500 Subject: [PATCH 0016/2516] improvements to travis setup -- cache, use command -v --- src/doc/rustc-dev-guide/.travis.yml | 4 +++- src/doc/rustc-dev-guide/ci/install.sh | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 5978c61d84548..36c3719f02378 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.travis.yml @@ -1,6 +1,8 @@ language: rust -cache: pip +cache: +- pip +- cargo install: - source ~/.cargo/env || true diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index dd96daf178fed..fac6488b68d1c 100644 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 68f0baedeb4e3fe59d3b2694ede9ae21a4ccce44 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 20 Jan 2018 22:13:39 +0800 Subject: [PATCH 0017/2516] Started working on the parser chapter --- src/doc/rustc-dev-guide/src/the-parser.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index ab756895ae6a9..a43ae3398fcf5 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 00363d7c56a21967146ffde3e13240dbcc4dde5f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 10:46:33 -0500 Subject: [PATCH 0018/2516] add an encrypted auth token --- src/doc/rustc-dev-guide/.travis.yml | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 36c3719f02378..4a2381fa75d10 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 016260eaf20f3fd06f9d29acbfea528012be1aa0 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 10:50:15 -0500 Subject: [PATCH 0019/2516] make `github_pages.sh` more chatty --- src/doc/rustc-dev-guide/ci/github_pages.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/github_pages.sh b/src/doc/rustc-dev-guide/ci/github_pages.sh index 603b280f98392..f5dd7898ba324 100644 --- a/src/doc/rustc-dev-guide/ci/github_pages.sh +++ b/src/doc/rustc-dev-guide/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 a1cb3131b576e660a21c471880230f2efc5dbe00 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 10:55:16 -0500 Subject: [PATCH 0020/2516] make install.sh tell us what it is installing and why --- src/doc/rustc-dev-guide/ci/install.sh | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index fac6488b68d1c..6cef274f86327 100644 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 1513fa9c92cf33ac1ab315dc6bbd6110ea62be1c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 10:58:54 -0500 Subject: [PATCH 0021/2516] invert the sense of `command -v` --- src/doc/rustc-dev-guide/ci/install.sh | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 6cef274f86327..49a251d448f62 100644 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 b8e890a9318f6c95c88c8264cfd7e7728943c112 Mon Sep 17 00:00:00 2001 From: Phil Ellison Date: Tue, 23 Jan 2018 20:04:27 +0000 Subject: [PATCH 0022/2516] Copy contents of README.md from librustc/hir --- src/doc/rustc-dev-guide/src/hir-lowering.md | 118 ++++++++++++++++++++ 1 file changed, 118 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/hir-lowering.md b/src/doc/rustc-dev-guide/src/hir-lowering.md index b2b6a7cdf8f36..e28bb4cd40ffc 100644 --- a/src/doc/rustc-dev-guide/src/hir-lowering.md +++ b/src/doc/rustc-dev-guide/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 10a1f97d71dce3b4309f99a56167d96888f996e0 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 16:36:56 -0500 Subject: [PATCH 0023/2516] try pip install --user --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 49a251d448f62..2d32caaa9a031 100644 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 e3bca40f952dc507a40295d8281608c5c231ecec Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 17:12:26 -0500 Subject: [PATCH 0024/2516] add `-p` flag to `ghp-import` so that it pushes --- src/doc/rustc-dev-guide/ci/github_pages.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/github_pages.sh b/src/doc/rustc-dev-guide/ci/github_pages.sh index f5dd7898ba324..b0dc26902bf45 100644 --- a/src/doc/rustc-dev-guide/ci/github_pages.sh +++ b/src/doc/rustc-dev-guide/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 39a09d577be63a033334ca5e2cd8a3e0a9016d69 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 21:45:25 -0500 Subject: [PATCH 0025/2516] try to use travis's builtin deploy workflow --- src/doc/rustc-dev-guide/.travis.yml | 7 +++++++ src/doc/rustc-dev-guide/ci/github_pages.sh | 1 - 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 4a2381fa75d10..7ecd57fd0e7ec 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/github_pages.sh b/src/doc/rustc-dev-guide/ci/github_pages.sh index b0dc26902bf45..ffd89ad522713 100644 --- a/src/doc/rustc-dev-guide/ci/github_pages.sh +++ b/src/doc/rustc-dev-guide/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 9a5ff03f18fb4e0d5a47a7039289cfb1cc37187e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 24 Jan 2018 04:17:48 -0500 Subject: [PATCH 0026/2516] try adjusting secure password again --- src/doc/rustc-dev-guide/.travis.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 7ecd57fd0e7ec..2d107794f4281 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 1f0212fe324037a3fcf078aad5b47a2e264cc3a3 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 24 Jan 2018 09:11:24 -0500 Subject: [PATCH 0027/2516] 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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 505836094d10f..de8a93bdd9125 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 25b889df387d8085f20bc7b54626a6d4a939b1ad Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Thu, 25 Jan 2018 00:30:52 +0800 Subject: [PATCH 0028/2516] Mentioned the main players in the parser --- src/doc/rustc-dev-guide/src/the-parser.md | 36 ++++++++++++++++++++--- 1 file changed, 32 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index a43ae3398fcf5..9a01d8a368c66 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 080f9a0b1fbf65303b90d2a0f1949dd9eec5873c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 25 Jan 2018 09:40:07 -0500 Subject: [PATCH 0029/2516] fix nits --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index de8a93bdd9125..f685f569c65d3 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 c83e283d7f8fb79c8f938aa90057296c534a3817 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 25 Jan 2018 15:56:06 -0600 Subject: [PATCH 0030/2516] Start macro expansion chapter --- src/doc/rustc-dev-guide/src/macro-expansion.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 12b95cb6cb074..7ab1c35bc782d 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 1b29e6ab7617ccfcb85387c99749b36e7570c256 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 25 Jan 2018 17:56:33 -0600 Subject: [PATCH 0031/2516] Add a bit about macro expansion --- .../src/src/chap-060-macro-expansion.md | 66 +++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md diff --git a/src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md b/src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md new file mode 100644 index 0000000000000..77f764d6a63b0 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 e28fd2fa799504c05191ede5e7c902c0c46cb524 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 25 Jan 2018 17:58:04 -0600 Subject: [PATCH 0032/2516] Oops rename --- .../rustc-dev-guide/src/macro-expansion.md | 62 +++++++++++++++-- .../src/src/chap-060-macro-expansion.md | 66 ------------------- 2 files changed, 58 insertions(+), 70 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 7ab1c35bc782d..77f764d6a63b0 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md b/src/doc/rustc-dev-guide/src/src/chap-060-macro-expansion.md deleted file mode 100644 index 77f764d6a63b0..0000000000000 --- a/src/doc/rustc-dev-guide/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 fad5a887a96ae2c942f81ee49098657cbec8f77f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 26 Jan 2018 09:11:52 -0500 Subject: [PATCH 0033/2516] rename the hir chapter to The HIR --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/{hir-lowering.md => hir.md} | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) rename src/doc/rustc-dev-guide/src/{hir-lowering.md => hir.md} (98%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index f8b1f1d6e0c1f..2e3b34386b849 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir-lowering.md b/src/doc/rustc-dev-guide/src/hir.md similarity index 98% rename from src/doc/rustc-dev-guide/src/hir-lowering.md rename to src/doc/rustc-dev-guide/src/hir.md index e28bb4cd40ffc..5d5e273c4792a 100644 --- a/src/doc/rustc-dev-guide/src/hir-lowering.md +++ b/src/doc/rustc-dev-guide/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 0f666a5997fcf585dc223720c569a93b931c6849 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 26 Jan 2018 09:20:01 -0500 Subject: [PATCH 0034/2516] move over the query chapter from src/librustc/ty/maps --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 + src/doc/rustc-dev-guide/src/query.md | 314 +++++++++++++++++++++++++ 2 files changed, 316 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/query.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 2e3b34386b849..e4bc24283c08e 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md new file mode 100644 index 0000000000000..65d651307ac39 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 964ac9d0bdd4fc794fee0558b5951f09d64b050b Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 26 Jan 2018 14:41:56 -0600 Subject: [PATCH 0035/2516] Updated macros to address Niko's comments --- .../rustc-dev-guide/src/macro-expansion.md | 172 +++++++++++++----- 1 file changed, 130 insertions(+), 42 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 77f764d6a63b0..dd735ed230b80 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 e0179611c433f5929f01908941165fb18d31e741 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 29 Jan 2018 09:59:47 -0500 Subject: [PATCH 0036/2516] breakup the MIR section and add an incremental compilation section --- src/doc/rustc-dev-guide/src/SUMMARY.md | 9 +- .../src/incremental-compilation.md | 139 ++++++++++++++++++ src/doc/rustc-dev-guide/src/mir.md | 1 + 3 files changed, 145 insertions(+), 4 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/incremental-compilation.md create mode 100644 src/doc/rustc-dev-guide/src/mir.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index e4bc24283c08e..8e18969a1f6c5 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/incremental-compilation.md b/src/doc/rustc-dev-guide/src/incremental-compilation.md new file mode 100644 index 0000000000000..23910c5b38917 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md new file mode 100644 index 0000000000000..2be6a2e1a84ee --- /dev/null +++ b/src/doc/rustc-dev-guide/src/mir.md @@ -0,0 +1 @@ +# The MIR (Mid-level IR) From b8d1ba80a55c97373db4eb76c78131dfefe44991 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 29 Jan 2018 10:25:44 -0500 Subject: [PATCH 0037/2516] create links in the glossary --- src/doc/rustc-dev-guide/src/glossary.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index b66e17ea3c18c..338c9e93f00ad 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 d4362bf8d7a13f652e03f8e3c55e0449e5d44907 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 29 Jan 2018 10:26:35 -0500 Subject: [PATCH 0038/2516] link glossary to mir --- src/doc/rustc-dev-guide/src/glossary.md | 2 +- src/doc/rustc-dev-guide/src/mir.md | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 338c9e93f00ad..3202e5f4ce354 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index 2be6a2e1a84ee..eeba6847295d1 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/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 5c2cc06d50a361afb449b387852342b224e2742f Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 29 Jan 2018 11:20:46 -0600 Subject: [PATCH 0039/2516] Rewrite 'tokens' para... --- .../rustc-dev-guide/src/macro-expansion.md | 26 ++++++++++++------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index dd735ed230b80..da4615128a2ba 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 2f55eef6123ce43494685f297f540bdd8c98a911 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 29 Jan 2018 11:37:40 -0600 Subject: [PATCH 0040/2516] I'm guessing this was a typo? --- src/doc/rustc-dev-guide/src/high-level-overview.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index b8d75bff69045..55b596a2a9c7c 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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 767893f428638c5401ac0dda32aa8f3af04509cd Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 29 Jan 2018 11:50:34 -0600 Subject: [PATCH 0041/2516] Corrected relationship of macro and rust parsers --- src/doc/rustc-dev-guide/src/macro-expansion.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index da4615128a2ba..a7777e80c3e9c 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 1790fa3747452a4d70c91730e666bce2b7d0783e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 29 Jan 2018 13:12:28 -0600 Subject: [PATCH 0042/2516] copy type inference readme --- src/doc/rustc-dev-guide/src/type-inference.md | 226 ++++++++++++++++++ 1 file changed, 226 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 0fc99252ab73a..6e2032feeab9c 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 54ef804087f56b6ac53dd99a0151299260a4c879 Mon Sep 17 00:00:00 2001 From: Michal 'vorner' Vaner Date: Mon, 29 Jan 2018 22:18:35 +0100 Subject: [PATCH 0043/2516] 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. --- .../rustc-dev-guide/src/name-resolution.md | 106 ++++++++++++++++++ 1 file changed, 106 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 487a31d2c5297..25ce3e29eb969 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 70e03964e924ee3b65bf413c1078c7bc9f3b340b Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 30 Jan 2018 11:38:37 -0600 Subject: [PATCH 0044/2516] Fix minor typos --- src/doc/rustc-dev-guide/src/incremental-compilation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/incremental-compilation.md b/src/doc/rustc-dev-guide/src/incremental-compilation.md index 23910c5b38917..df88125e126f5 100644 --- a/src/doc/rustc-dev-guide/src/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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 aa9cd4423ea993bcc0092cc114deb8063a993f00 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 30 Jan 2018 16:29:16 -0600 Subject: [PATCH 0045/2516] Add a para about bootstrapping --- .../rustc-dev-guide/src/how-to-build-and-run.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index f685f569c65d3..24cfbfad72b11 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 de5e7cac046e6b96c3ebc4d5895a0b7096c3df69 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Wed, 31 Jan 2018 01:20:07 +0000 Subject: [PATCH 0046/2516] improved grammar use en-dashes instead of `--` --- src/doc/rustc-dev-guide/src/about-this-guide.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index ea840177b55b4..79106736ffdb8 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 d959cf609cbfe7a16424b407d2dc9f7411af28f5 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Wed, 31 Jan 2018 01:32:49 +0000 Subject: [PATCH 0047/2516] improved grammar and fixed small errors --- .../src/incremental-compilation.md | 33 +++++++++---------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/incremental-compilation.md b/src/doc/rustc-dev-guide/src/incremental-compilation.md index df88125e126f5..5cee70dbd2b7a 100644 --- a/src/doc/rustc-dev-guide/src/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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 a3961062015b21793087eb0362ca3ffc8fe6584d Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Wed, 31 Jan 2018 02:08:14 +0000 Subject: [PATCH 0048/2516] fixed grammatical oversight --- src/doc/rustc-dev-guide/src/incremental-compilation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/incremental-compilation.md b/src/doc/rustc-dev-guide/src/incremental-compilation.md index 5cee70dbd2b7a..2ab053e1730a1 100644 --- a/src/doc/rustc-dev-guide/src/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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 d797aaecca4e8c8ab49cefd3b9977d5e56ec6ca1 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Wed, 31 Jan 2018 02:09:24 +0000 Subject: [PATCH 0049/2516] minor clarification --- src/doc/rustc-dev-guide/src/incremental-compilation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/incremental-compilation.md b/src/doc/rustc-dev-guide/src/incremental-compilation.md index 2ab053e1730a1..dc4d06c6c3532 100644 --- a/src/doc/rustc-dev-guide/src/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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 05d24370cd15dbe494f777c9a5fc61b0be1ce765 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Wed, 31 Jan 2018 02:09:59 +0000 Subject: [PATCH 0050/2516] changed hyphens to en-dashes --- src/doc/rustc-dev-guide/src/the-parser.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index 9a01d8a368c66..456f0a9eaa7a9 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 a8b512e2b1c7d6fe3841efc88520ec9694411299 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 31 Jan 2018 12:22:42 -0600 Subject: [PATCH 0051/2516] copy MIR readme --- src/doc/rustc-dev-guide/src/mir.md | 105 ++++++++++++++++++++++++++++- 1 file changed, 102 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index eeba6847295d1..dbac8eb53f645 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/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 b9ad5b05a419c99b7a4e744d2671a90f7d840d1a Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 27 Jan 2018 14:30:07 +0800 Subject: [PATCH 0052/2516] Added the mdbook-linkcheck backend --- src/doc/rustc-dev-guide/book.toml | 3 +++ src/doc/rustc-dev-guide/src/high-level-overview.md | 4 +++- src/doc/rustc-dev-guide/src/ty.md | 2 +- 3 files changed, 7 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 485a12ca3bbda..3c4c537e8b322 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 55b596a2a9c7c..7da9b8ca19b69 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 8debb71c788e5..906e99e713597 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 173a1083ea65b498d27ede37d841b02a4c5e7e65 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 27 Jan 2018 14:36:23 +0800 Subject: [PATCH 0053/2516] Updated CI to install and use mdbook-linkcheck --- src/doc/rustc-dev-guide/ci/install.sh | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 2d32caaa9a031..81cbd8fb72de3 100644 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 f48a68e481e2ce8eaf90f6471200569030102f3a Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 27 Jan 2018 14:41:40 +0800 Subject: [PATCH 0054/2516] Removed ghp-import and run mdbook build unconditionally --- src/doc/rustc-dev-guide/.travis.yml | 5 +---- src/doc/rustc-dev-guide/ci/github_pages.sh | 11 ----------- src/doc/rustc-dev-guide/ci/install.sh | 7 ------- 3 files changed, 1 insertion(+), 22 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/ci/github_pages.sh diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 2d107794f4281..0862ff9bbf2f8 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/github_pages.sh b/src/doc/rustc-dev-guide/ci/github_pages.sh deleted file mode 100644 index ffd89ad522713..0000000000000 --- a/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 81cbd8fb72de3..99c85986cbb31 100644 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 fa38aac34cb41e8698eb2e6e68693a5c104d0a8d Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 27 Jan 2018 14:53:46 +0800 Subject: [PATCH 0055/2516] Added a note about how to use mdbook-linkcheck --- src/doc/rustc-dev-guide/README.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 5ff51de2b7382..352c4ce0ba5ab 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 31a66439e05e3de1a6f9dee347b658031de91f24 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 27 Jan 2018 14:54:56 +0800 Subject: [PATCH 0056/2516] Toned down the log verbosity --- src/doc/rustc-dev-guide/.travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 0862ff9bbf2f8..f17a947d4c880 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 51fc35b7cf49aba08c0e63bf4efeeb3197a98541 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 31 Jan 2018 11:30:17 -0500 Subject: [PATCH 0057/2516] update to link within the book --- src/doc/rustc-dev-guide/src/high-level-overview.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 7da9b8ca19b69..519d822e27084 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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 f0ab2ecf95c9e8289718dd6a03d0601e2a9d5690 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 31 Jan 2018 11:31:43 -0500 Subject: [PATCH 0058/2516] Update link to hir --- src/doc/rustc-dev-guide/src/ty.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 906e99e713597..e29ecb5e3ddae 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 986380820154c63cdff0da94c2926d4da54c9882 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 31 Jan 2018 14:13:49 -0500 Subject: [PATCH 0059/2516] fix some broken links --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- src/doc/rustc-dev-guide/src/type-inference.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index a7777e80c3e9c..ee4bd322cb251 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 6e2032feeab9c..feb694196bf9c 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 12243df6b46ea6dbe142171bb5177f8b4311b968 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 31 Jan 2018 14:18:51 -0500 Subject: [PATCH 0060/2516] update wording to be a bit more clear --- .../rustc-dev-guide/src/how-to-build-and-run.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 24cfbfad72b11..7992dc987436f 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 7b236a4f66fa086cf26796df0a42bf57010e1ef3 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Thu, 1 Feb 2018 03:47:39 +0000 Subject: [PATCH 0061/2516] fixed definition of code_mr hyperlink --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index ee4bd322cb251..8f94d6a0a1a37 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 f4a835250105c09b3901a35562aef86aac7e7e65 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Thu, 1 Feb 2018 03:50:28 +0000 Subject: [PATCH 0062/2516] replaced all instances of `--` (double hyphen) with `-` (en-dash) --- .../rustc-dev-guide/src/high-level-overview.md | 8 ++++---- src/doc/rustc-dev-guide/src/hir.md | 6 +++--- .../src/how-to-build-and-run.md | 10 +++++----- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- src/doc/rustc-dev-guide/src/mir.md | 10 +++++----- src/doc/rustc-dev-guide/src/query.md | 4 ++-- .../rustc-dev-guide/src/trait-resolution.md | 18 +++++++++--------- src/doc/rustc-dev-guide/src/ty.md | 12 ++++++------ src/doc/rustc-dev-guide/src/type-inference.md | 12 ++++++------ 9 files changed, 41 insertions(+), 41 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 519d822e27084..50ed072b884a9 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 5d5e273c4792a..52fda69a6fc32 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 7992dc987436f..2657da84c986f 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 8f94d6a0a1a37..55a550b56e8b7 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index dbac8eb53f645..34f6bbb8ff1b5 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 65d651307ac39..fa17a3850b803 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index 58efbd05039e9..63f72b014fbcb 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index e29ecb5e3ddae..0732e88bde01a 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index feb694196bf9c..070b7bb4c8421 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 0d2e27c3d03fd58a026ab2fb2fd099559d0f458c Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Thu, 1 Feb 2018 03:57:51 +0000 Subject: [PATCH 0063/2516] minor grammatical fixes --- src/doc/rustc-dev-guide/src/macro-expansion.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 55a550b56e8b7..a43c0939452ce 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 f2a5c4b57b0d1f985737f23fb2a3d819df030df1 Mon Sep 17 00:00:00 2001 From: avborhanian Date: Sat, 3 Feb 2018 00:51:25 -0500 Subject: [PATCH 0064/2516] Adding ICH to the glossary. --- src/doc/rustc-dev-guide/src/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 3202e5f4ce354..186e1a4c7936e 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 90cf3918cfe4692cefdaef7e1f0c268d497cf97f Mon Sep 17 00:00:00 2001 From: avborhanian Date: Sun, 4 Feb 2018 13:46:29 -0500 Subject: [PATCH 0065/2516] Update glossary.md --- src/doc/rustc-dev-guide/src/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 186e1a4c7936e..ee27362af3f47 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 444b4b9c06878eca97613e4848d1dab07cd67714 Mon Sep 17 00:00:00 2001 From: avborhanian Date: Sun, 4 Feb 2018 13:54:45 -0500 Subject: [PATCH 0066/2516] Update glossary.md --- src/doc/rustc-dev-guide/src/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index ee27362af3f47..10c2d45355ee5 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 0976bb3c90ab04adeaf9e3ea0437ce91284ba434 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 4 Feb 2018 16:11:19 -0600 Subject: [PATCH 0067/2516] Update README.md --- src/doc/rustc-dev-guide/README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 352c4ce0ba5ab..7e468fbb0db97 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 41bb7504d771dafb005a9daee57549f683397ccc Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 18:37:37 +0000 Subject: [PATCH 0068/2516] Renamed `trans: generating LLVM IR` section. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/trans.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 8e18969a1f6c5..8f128f6488d8b 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trans.md b/src/doc/rustc-dev-guide/src/trans.md index 7092b7a0baf06..efff52ef982d2 100644 --- a/src/doc/rustc-dev-guide/src/trans.md +++ b/src/doc/rustc-dev-guide/src/trans.md @@ -1 +1 @@ -# trans: generating LLVM IR +# The `trans` crate: generating LLVM IR From d8b560076aeb950b7b760131370161abb7cc231b Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 18:48:38 +0000 Subject: [PATCH 0069/2516] Improved grammar of HIR section. --- src/doc/rustc-dev-guide/src/hir.md | 89 +++++++++++++++--------------- 1 file changed, 43 insertions(+), 46 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 52fda69a6fc32..ac7690bd54734 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 f2fb102fac8ae42d5afbfa689d234b61a5bd65a2 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 18:49:41 +0000 Subject: [PATCH 0070/2516] Changed all instances of `e.g.,` to `e.g.`, and similar. --- src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md | 4 ++-- src/doc/rustc-dev-guide/src/glossary.md | 2 +- src/doc/rustc-dev-guide/src/high-level-overview.md | 6 +++--- src/doc/rustc-dev-guide/src/hir.md | 2 +- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- src/doc/rustc-dev-guide/src/query.md | 4 ++-- src/doc/rustc-dev-guide/src/trait-resolution.md | 2 +- src/doc/rustc-dev-guide/src/type-inference.md | 2 +- 8 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md b/src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md index d42476bc4130d..89a9cdfcce074 100644 --- a/src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 10c2d45355ee5..91af4c7da79cc 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 50ed072b884a9..0d3ad8be523b1 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index ac7690bd54734..d7eff5cd967fb 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index a43c0939452ce..95ea64f191546 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index fa17a3850b803..d119c16f3d38c 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index 63f72b014fbcb..1c7f09e9be72f 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 070b7bb4c8421..8155829fe915a 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 79896e6cb29a78e020466244bbd58f7535680848 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 21:15:46 +0000 Subject: [PATCH 0071/2516] Normalized instances of `N.B.`. --- src/doc/rustc-dev-guide/src/query.md | 2 +- src/doc/rustc-dev-guide/src/ty.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index d119c16f3d38c..481b4fed3c8b5 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 0732e88bde01a..8b72d440fc8ef 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 c45b135799d6263d4df7bcdb7fa14f13c78b8007 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 21:24:50 +0000 Subject: [PATCH 0072/2516] Very minor grammatical fixes. --- src/doc/rustc-dev-guide/src/ty.md | 2 +- src/doc/rustc-dev-guide/src/type-inference.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 8b72d440fc8ef..1da70d916f724 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 8155829fe915a..ef97e59d86002 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 198054ea5305132757dcf94f6522871990373891 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 21:28:29 +0000 Subject: [PATCH 0073/2516] Explained what HM type inference is. --- src/doc/rustc-dev-guide/src/type-inference.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index ef97e59d86002..2cc922c765610 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 61450e53644df9c399b1bad076ac1d460946349e Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 21:41:49 +0000 Subject: [PATCH 0074/2516] Cleaned up section on type inference. --- src/doc/rustc-dev-guide/src/type-inference.md | 43 +++++++++---------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 2cc922c765610..b867c99e2cf3f 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 be90a131125b18296853130d305d2e70c45b34a0 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Mon, 5 Feb 2018 02:30:32 +0000 Subject: [PATCH 0075/2516] More minor fixes. --- src/doc/rustc-dev-guide/src/hir.md | 4 ++-- src/doc/rustc-dev-guide/src/trait-resolution.md | 2 +- src/doc/rustc-dev-guide/src/ty.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index d7eff5cd967fb..504f04b24082f 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index 1c7f09e9be72f..f12ce3b4b15bb 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 1da70d916f724..26b8c1ca8ff49 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 e50733d6237121b5a9af0666303806b7c8e680b8 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Mon, 5 Feb 2018 02:15:36 +0000 Subject: [PATCH 0076/2516] Fixed issues mentioned by @mark-i-m in review. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/high-level-overview.md | 12 ++++++------ src/doc/rustc-dev-guide/src/hir.md | 6 +++--- src/doc/rustc-dev-guide/src/trans.md | 2 +- src/doc/rustc-dev-guide/src/type-inference.md | 8 ++++---- 5 files changed, 15 insertions(+), 15 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 8f128f6488d8b..a2f40ed353a9c 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 0d3ad8be523b1..493656713a75e 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 504f04b24082f..f78d2add20e5c 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trans.md b/src/doc/rustc-dev-guide/src/trans.md index efff52ef982d2..f5894baa795a6 100644 --- a/src/doc/rustc-dev-guide/src/trans.md +++ b/src/doc/rustc-dev-guide/src/trans.md @@ -1 +1 @@ -# The `trans` crate: generating LLVM IR +# Generating LLVM IR diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index b867c99e2cf3f..5e51c73584ea3 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 b93b55de10e44ec582d6c7bba72665cf504626ac Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Mon, 5 Feb 2018 03:43:46 +0000 Subject: [PATCH 0077/2516] Removed spurious `a`. --- src/doc/rustc-dev-guide/src/type-inference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 5e51c73584ea3..327bd530ac51d 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 54360bc43b515f6c3321655d5d8df780beca5884 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 4 Feb 2018 21:51:10 -0600 Subject: [PATCH 0078/2516] Update link text --- src/doc/rustc-dev-guide/src/type-inference.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 327bd530ac51d..c4307ce7f252c 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 fd21533d7fefec1f15fbb2b16de75b5bed960670 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Mon, 5 Feb 2018 20:39:35 +0100 Subject: [PATCH 0079/2516] Add DAG to glossary --- src/doc/rustc-dev-guide/src/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 91af4c7da79cc..de1390d530cac 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 89e5f5bd7b353030185c472d34a60e429d10a9c1 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 6 Feb 2018 07:54:03 +0100 Subject: [PATCH 0080/2516] Order alphabetically, improve explanation of DAG --- src/doc/rustc-dev-guide/src/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index de1390d530cac..119e73255b2de 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 885d05a33a1aaa112c7482ff931ca008b1ce43d4 Mon Sep 17 00:00:00 2001 From: Phil Ellison Date: Wed, 7 Feb 2018 07:08:58 +0000 Subject: [PATCH 0081/2516] Explain how to dump HIR --- src/doc/rustc-dev-guide/src/hir.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 52fda69a6fc32..1293368748dae 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 5d9b5af48031b348031c0410cadbcb0ccac2d595 Mon Sep 17 00:00:00 2001 From: Phil Ellison Date: Wed, 7 Feb 2018 19:14:58 +0000 Subject: [PATCH 0082/2516] Use cargo rustc instead of setting RUSTFLAGS --- src/doc/rustc-dev-guide/src/hir.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 1293368748dae..f3145925ce9f9 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 12523efb8ddf4e2549db48a27634b462281fee26 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 11 Feb 2018 15:46:36 -0600 Subject: [PATCH 0083/2516] alphabetize glossary --- src/doc/rustc-dev-guide/src/glossary.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 119e73255b2de..b7282c3eb6101 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 eef281139ff2c9a96580ef676600d067decf04b2 Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Tue, 13 Feb 2018 05:53:35 -0800 Subject: [PATCH 0084/2516] created compiletest.md describe the steps required to add a test and a header command to compiletest --- src/doc/rustc-dev-guide/src/compiletest.md | 183 +++++++++++++++++++++ 1 file changed, 183 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/compiletest.md diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md new file mode 100644 index 0000000000000..a8942efba4e25 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 7f8475330d8a2250d7ec6da4a91beed3e39b3a71 Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Tue, 13 Feb 2018 09:22:33 -0800 Subject: [PATCH 0085/2516] Update compiletest.md changed file references to GitHub links directly to files --- src/doc/rustc-dev-guide/src/compiletest.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index a8942efba4e25..aa4558514ee94 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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 0ac3b004e84b7878dd8146616111ce4b5380b32e Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Tue, 13 Feb 2018 09:45:26 -0800 Subject: [PATCH 0086/2516] fixed typos --- src/doc/rustc-dev-guide/src/compiletest.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index aa4558514ee94..0b10cfbb774f5 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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 baafc5b354f289210dc0537fe9b646bdf1ae0406 Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Tue, 13 Feb 2018 09:53:45 -0800 Subject: [PATCH 0087/2516] Added 'How to add header commands to `compiletest`' --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index a2f40ed353a9c..6a3907551bc77 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 76ffbac762bacd5276978729284448adba38185c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 13 Feb 2018 11:00:42 -0600 Subject: [PATCH 0088/2516] add soundness and completeness to glossary --- src/doc/rustc-dev-guide/src/glossary.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index b7282c3eb6101..cb3437f1dacc4 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 22467f2498e79cc1558a4f13179e4ac0055d99bf Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 13 Feb 2018 11:20:19 -0600 Subject: [PATCH 0089/2516] Update glossary.md --- src/doc/rustc-dev-guide/src/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index cb3437f1dacc4..a22c496327cdf 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 60feb91f1501c8f910c081f70541cdfe65e03dc1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 15 Feb 2018 12:53:49 -0600 Subject: [PATCH 0090/2516] Add a few more terms to the glossary --- src/doc/rustc-dev-guide/src/glossary.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index a22c496327cdf..f252e6956939d 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 77e034cef4c914cdd02280cf198d60ff802ed34b Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 7 Feb 2018 09:47:02 -0500 Subject: [PATCH 0091/2516] document the test infrastructure --- src/doc/rustc-dev-guide/src/SUMMARY.md | 4 +- src/doc/rustc-dev-guide/src/running-tests.md | 1 - src/doc/rustc-dev-guide/src/tests/adding.md | 273 +++++++++++++++++++ src/doc/rustc-dev-guide/src/tests/intro.md | 48 ++++ src/doc/rustc-dev-guide/src/tests/running.md | 65 +++++ 5 files changed, 389 insertions(+), 2 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/running-tests.md create mode 100644 src/doc/rustc-dev-guide/src/tests/adding.md create mode 100644 src/doc/rustc-dev-guide/src/tests/intro.md create mode 100644 src/doc/rustc-dev-guide/src/tests/running.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index a2f40ed353a9c..21976fbf7e567 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/running-tests.md b/src/doc/rustc-dev-guide/src/running-tests.md deleted file mode 100644 index 02c9de84067fa..0000000000000 --- a/src/doc/rustc-dev-guide/src/running-tests.md +++ /dev/null @@ -1 +0,0 @@ -# Using the compiler testing framework diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md new file mode 100644 index 0000000000000..9ce8318db2372 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md new file mode 100644 index 0000000000000..c22916dca778d --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md new file mode 100644 index 0000000000000..8813862d8a389 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 936dabd6aa3886c9a213d53a42b086d985293c7f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 09:41:13 -0500 Subject: [PATCH 0092/2516] add some notes on coding conventions and link to copyright notice --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/conventions.md | 63 +++++++++++++++++++++ src/doc/rustc-dev-guide/src/tests/adding.md | 2 +- 3 files changed, 65 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/src/conventions.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 21976fbf7e567..981eb22c9a121 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md new file mode 100644 index 0000000000000..14ef7119a0732 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 9ce8318db2372..ae247010d879a 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 b394e3c9f43f84194901e98a96651d9b61ca485d Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 09:59:50 -0500 Subject: [PATCH 0093/2516] add some more conventions --- src/doc/rustc-dev-guide/src/conventions.md | 106 ++++++++++++++++++--- 1 file changed, 95 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 14ef7119a0732..93a07ad43d354 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 f00f4fa80ce42607e4df374bb5c725e2fda32ff1 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:17:23 -0500 Subject: [PATCH 0094/2516] give some advice about which test suite to use --- src/doc/rustc-dev-guide/src/tests/adding.md | 71 +++++++++++++++------ src/doc/rustc-dev-guide/src/tests/intro.md | 15 +++-- 2 files changed, 59 insertions(+), 27 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index ae247010d879a..c2a5ef43fe86d 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index c22916dca778d..334042a41bac7 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 2c503ac9479d246b5e7834dedeefed77d5155160 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:18:27 -0500 Subject: [PATCH 0095/2516] complete sentence --- src/doc/rustc-dev-guide/src/tests/running.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 8813862d8a389..59a615dab0f64 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 87a20eed90fd7b131ed1281232427a69a9ce1729 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:21:27 -0500 Subject: [PATCH 0096/2516] link to brson's blog post --- src/doc/rustc-dev-guide/src/tests/intro.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 334042a41bac7..1e4a2bed3294a 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 82f7f71d218618e7fc0a5563829e7281f7085432 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:21:32 -0500 Subject: [PATCH 0097/2516] fix typo --- src/doc/rustc-dev-guide/src/tests/running.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 59a615dab0f64..98d590671c93b 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 32a8b6f41e5e21904dc275de4c0f3adf55ce3688 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:27:57 -0500 Subject: [PATCH 0098/2516] mention tidy --- src/doc/rustc-dev-guide/src/conventions.md | 4 ++-- src/doc/rustc-dev-guide/src/tests/running.md | 7 +++++++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 93a07ad43d354..3ed58bf49208e 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 98d590671c93b..dc9de0019bf8a 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 57ccda92e85c55cab76a97466d7b3a24b6da4a74 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:31:48 -0500 Subject: [PATCH 0099/2516] correct links (mdbook seems to want them relative to the book root) --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 2 +- src/doc/rustc-dev-guide/src/tests/adding.md | 2 +- src/doc/rustc-dev-guide/src/tests/intro.md | 6 +++--- src/doc/rustc-dev-guide/src/tests/running.md | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 2657da84c986f..7b6088c7c0ea1 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index c2a5ef43fe86d..276189f59c8c8 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 1e4a2bed3294a..615673206fe6e 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index dc9de0019bf8a..602aa51d9b021 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 468407fc7440c385cd407f9d1a03e9d91d3a7e56 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:32:35 -0500 Subject: [PATCH 0100/2516] remove humorous footnote which is not supported --- src/doc/rustc-dev-guide/src/conventions.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 3ed58bf49208e..f7ef86f11468c 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 a2a18373cd7a0578674b8f273696dfdb46168f05 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sat, 17 Feb 2018 20:24:48 -0800 Subject: [PATCH 0101/2516] Force mdbook update on CI if there is a version mismatch. Fixes #58. --- src/doc/rustc-dev-guide/ci/install.sh | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 99c85986cbb31..a5d87a6bc3b2f 100644 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 2d12294215279b7f182af6fe8304235df81c2e2b Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sat, 17 Feb 2018 20:35:57 -0800 Subject: [PATCH 0102/2516] Fix Github Pages path. The newer version of mdBook uses a different path for the html output. --- src/doc/rustc-dev-guide/.travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index f17a947d4c880..5ca97ba79df17 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 6947abdcf3ec34b1e5a88390e663b4661229fedc Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Tue, 20 Feb 2018 15:32:17 -0800 Subject: [PATCH 0103/2516] added compiletest to summary.md; linked to existing resources for additional information --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/compiletest.md | 6 ++++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 6a3907551bc77..1926a58cfc19b 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 0b10cfbb774f5..e080e6ce7b52c 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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 3f2a672b7fea7936586f410d56dc4aab6b0cabdc Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Wed, 21 Feb 2018 07:44:07 -0800 Subject: [PATCH 0104/2516] cleaned up some stragglers --- src/doc/rustc-dev-guide/src/compiletest.md | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index e080e6ce7b52c..854796adbe747 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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 fbb307811af836c102d965cd9e4dff3cfc82e870 Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Wed, 21 Feb 2018 10:44:23 -0800 Subject: [PATCH 0105/2516] changed to relative links, where possible --- src/doc/rustc-dev-guide/src/compiletest.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 854796adbe747..f07d3065a425e 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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 316c5e970fab077f231ca39cb98f17a1a974d957 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Tue, 6 Feb 2018 19:10:04 +0100 Subject: [PATCH 0106/2516] Add some documentation for const eval and related topics --- src/doc/rustc-dev-guide/src/SUMMARY.md | 3 + src/doc/rustc-dev-guide/src/const-eval.md | 37 +++++ src/doc/rustc-dev-guide/src/glossary.md | 3 + src/doc/rustc-dev-guide/src/miri.md | 142 ++++++++++++++++++ src/doc/rustc-dev-guide/src/param_env.md | 30 ++++ .../rustc-dev-guide/src/trait-resolution.md | 2 +- 6 files changed, 216 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/src/const-eval.md create mode 100644 src/doc/rustc-dev-guide/src/miri.md create mode 100644 src/doc/rustc-dev-guide/src/param_env.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index cb15c2c7172b1..ea2a6cd98d4ce 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/const-eval.md b/src/doc/rustc-dev-guide/src/const-eval.md new file mode 100644 index 0000000000000..3fb65216afe5f --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index a22c496327cdf..34b4bd446b1a6 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md new file mode 100644 index 0000000000000..4b0a600bebe93 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/param_env.md b/src/doc/rustc-dev-guide/src/param_env.md new file mode 100644 index 0000000000000..2474886efea6e --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index f12ce3b4b15bb..10a5539e49234 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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 43388e49cff26e0b5ba9f97709268cf811d92738 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Feb 2018 15:22:38 -0600 Subject: [PATCH 0107/2516] Clean up and reorganize traits chapter --- src/doc/rustc-dev-guide/src/SUMMARY.md | 3 + src/doc/rustc-dev-guide/src/trait-caching.md | 54 +++ src/doc/rustc-dev-guide/src/trait-hrtb.md | 116 +++++ .../rustc-dev-guide/src/trait-resolution.md | 402 +++++------------- .../src/trait-specialization.md | 39 ++ 5 files changed, 322 insertions(+), 292 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/trait-caching.md create mode 100644 src/doc/rustc-dev-guide/src/trait-hrtb.md create mode 100644 src/doc/rustc-dev-guide/src/trait-specialization.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index ea2a6cd98d4ce..af7dfbd665c77 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-caching.md b/src/doc/rustc-dev-guide/src/trait-caching.md new file mode 100644 index 0000000000000..6a0e55b27222d --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-hrtb.md b/src/doc/rustc-dev-guide/src/trait-hrtb.md new file mode 100644 index 0000000000000..f0c47d942581b --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index 10a5539e49234..1cad488ac5eb0 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-specialization.md b/src/doc/rustc-dev-guide/src/trait-specialization.md new file mode 100644 index 0000000000000..6b8bc64ddcd2a --- /dev/null +++ b/src/doc/rustc-dev-guide/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 a1d300c96995ca3e6dc471f3b9b4dae12497b3f6 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Feb 2018 17:22:23 -0600 Subject: [PATCH 0108/2516] Clarifications and edits to hrtb chapter --- src/doc/rustc-dev-guide/src/trait-caching.md | 1 - src/doc/rustc-dev-guide/src/trait-hrtb.md | 41 ++++++++++++-------- 2 files changed, 25 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/trait-caching.md b/src/doc/rustc-dev-guide/src/trait-caching.md index 6a0e55b27222d..31f398ff528fe 100644 --- a/src/doc/rustc-dev-guide/src/trait-caching.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-hrtb.md b/src/doc/rustc-dev-guide/src/trait-hrtb.md index f0c47d942581b..8c3a6f4e969c6 100644 --- a/src/doc/rustc-dev-guide/src/trait-hrtb.md +++ b/src/doc/rustc-dev-guide/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 c5d64c53559011416f62fae1a35e325cc04d2326 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Feb 2018 17:49:56 -0600 Subject: [PATCH 0109/2516] Edits and cleanup in trait-caching subchapter --- src/doc/rustc-dev-guide/src/trait-caching.md | 44 +++++++++++++------- 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/trait-caching.md b/src/doc/rustc-dev-guide/src/trait-caching.md index 31f398ff528fe..ee92814cdba12 100644 --- a/src/doc/rustc-dev-guide/src/trait-caching.md +++ b/src/doc/rustc-dev-guide/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 9cd08f4fa1e193e02530e05844338b023e2c8bc1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Feb 2018 17:55:06 -0600 Subject: [PATCH 0110/2516] Minor updates to specialization subchapter --- src/doc/rustc-dev-guide/src/trait-specialization.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/trait-specialization.md b/src/doc/rustc-dev-guide/src/trait-specialization.md index 6b8bc64ddcd2a..671e5e01682f5 100644 --- a/src/doc/rustc-dev-guide/src/trait-specialization.md +++ b/src/doc/rustc-dev-guide/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 871ca87f80d8bbead5d337b844ed25a2e4929fac Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 23 Feb 2018 10:18:16 -0800 Subject: [PATCH 0111/2516] Add some more information about the various tests that get run. CC #10 --- src/doc/rustc-dev-guide/src/tests/intro.md | 74 +++++++++++++++++--- src/doc/rustc-dev-guide/src/tests/running.md | 7 -- 2 files changed, 65 insertions(+), 16 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 615673206fe6e..2388e43081f18 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 602aa51d9b021..98d590671c93b 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 c7854cd88d89478215b8e6b9b3814454f4bc51e7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 13 Feb 2018 11:17:45 -0600 Subject: [PATCH 0112/2516] Start a code index --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/code-index.md | 9 +++++++++ 2 files changed, 10 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/code-index.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index ea2a6cd98d4ce..04904bce7869d 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/code-index.md b/src/doc/rustc-dev-guide/src/code-index.md new file mode 100644 index 0000000000000..5b452ef0f1102 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 4468d92ff253d4d79f114e172be94936e342f6cf Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Feb 2018 13:17:29 -0600 Subject: [PATCH 0113/2516] Add HIR MAP to glossary --- src/doc/rustc-dev-guide/src/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 34b4bd446b1a6..13567a4286c33 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 59467e927f61ff36a33099147209836d44ae527e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 15 Feb 2018 12:46:42 -0600 Subject: [PATCH 0114/2516] Add some codegen related terminology to glossary --- src/doc/rustc-dev-guide/src/glossary.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index a770bdf8e1a79..5d76cf3cfdb94 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 34f9fb2dcb151cf7051ac1c0fe10dd95788f93b7 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sat, 24 Feb 2018 12:50:48 -0800 Subject: [PATCH 0115/2516] Start documentation for test infrastructure. CC #10 --- src/doc/rustc-dev-guide/src/tests/intro.md | 67 +++++++++++++++++++++- 1 file changed, 66 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 2388e43081f18..8ad2492b76920 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 eed5c310bea56d7112b8260fc722f3e221bd431c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 24 Feb 2018 17:14:56 -0500 Subject: [PATCH 0116/2516] rework the MIR intro section, breaking out passes and visitors --- src/doc/rustc-dev-guide/src/SUMMARY.md | 4 + src/doc/rustc-dev-guide/src/background.md | 122 ++++++ src/doc/rustc-dev-guide/src/glossary.md | 2 + src/doc/rustc-dev-guide/src/mir-background.md | 122 ++++++ src/doc/rustc-dev-guide/src/mir-borrowck.md | 57 ++- src/doc/rustc-dev-guide/src/mir-passes.md | 169 ++++++++ src/doc/rustc-dev-guide/src/mir-regionck.md | 376 ++++++++++++++++++ src/doc/rustc-dev-guide/src/mir-visitor.md | 45 +++ src/doc/rustc-dev-guide/src/mir.md | 303 ++++++++++---- 9 files changed, 1121 insertions(+), 79 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/background.md create mode 100644 src/doc/rustc-dev-guide/src/mir-background.md create mode 100644 src/doc/rustc-dev-guide/src/mir-passes.md create mode 100644 src/doc/rustc-dev-guide/src/mir-regionck.md create mode 100644 src/doc/rustc-dev-guide/src/mir-visitor.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 4ead057054ee7..29ad7999886db 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/background.md b/src/doc/rustc-dev-guide/src/background.md new file mode 100644 index 0000000000000..92ae6507a596f --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 5d76cf3cfdb94..2aa9b52f192d3 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-background.md b/src/doc/rustc-dev-guide/src/mir-background.md new file mode 100644 index 0000000000000..38fba5d16a624 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-borrowck.md b/src/doc/rustc-dev-guide/src/mir-borrowck.md index 55bc9fc982af2..b632addc2f706 100644 --- a/src/doc/rustc-dev-guide/src/mir-borrowck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-passes.md b/src/doc/rustc-dev-guide/src/mir-passes.md new file mode 100644 index 0000000000000..2fe4713851aeb --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-regionck.md b/src/doc/rustc-dev-guide/src/mir-regionck.md new file mode 100644 index 0000000000000..8be4fc8b92e18 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-visitor.md b/src/doc/rustc-dev-guide/src/mir-visitor.md new file mode 100644 index 0000000000000..824ddd5b27945 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index 34f6bbb8ff1b5..262082ed776b9 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/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 410136c80157c1b0f3e558a3b101576190395af6 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sun, 25 Feb 2018 20:55:56 -0500 Subject: [PATCH 0117/2516] apply mark-i-m's suggestions --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/background.md | 20 +-- src/doc/rustc-dev-guide/src/glossary.md | 12 +- src/doc/rustc-dev-guide/src/mir-background.md | 122 ------------- src/doc/rustc-dev-guide/src/mir-borrowck.md | 8 +- src/doc/rustc-dev-guide/src/mir-passes.md | 36 ++-- src/doc/rustc-dev-guide/src/mir-regionck.md | 167 +++++++++++++++--- src/doc/rustc-dev-guide/src/mir-visitor.md | 10 ++ src/doc/rustc-dev-guide/src/mir.md | 34 ++-- 9 files changed, 209 insertions(+), 202 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/mir-background.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 29ad7999886db..ab9da7295c63f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/background.md b/src/doc/rustc-dev-guide/src/background.md index 92ae6507a596f..50c247774e7ba 100644 --- a/src/doc/rustc-dev-guide/src/background.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 2aa9b52f192d3..81eb62bc9aeb8 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-background.md b/src/doc/rustc-dev-guide/src/mir-background.md deleted file mode 100644 index 38fba5d16a624..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-borrowck.md b/src/doc/rustc-dev-guide/src/mir-borrowck.md index b632addc2f706..3c10191d4c2be 100644 --- a/src/doc/rustc-dev-guide/src/mir-borrowck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-passes.md b/src/doc/rustc-dev-guide/src/mir-passes.md index 2fe4713851aeb..6d657ae70744f 100644 --- a/src/doc/rustc-dev-guide/src/mir-passes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-regionck.md b/src/doc/rustc-dev-guide/src/mir-regionck.md index 8be4fc8b92e18..d9d8540814611 100644 --- a/src/doc/rustc-dev-guide/src/mir-regionck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-visitor.md b/src/doc/rustc-dev-guide/src/mir-visitor.md index 824ddd5b27945..3a8b06c543a02 100644 --- a/src/doc/rustc-dev-guide/src/mir-visitor.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index 262082ed776b9..6e7ac06916abe 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/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 ba6a7f2efa6358f91cb606a4dff81830b64cda46 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 27 Feb 2018 14:16:18 -0500 Subject: [PATCH 0118/2516] fix typo --- src/doc/rustc-dev-guide/src/mir-regionck.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir-regionck.md b/src/doc/rustc-dev-guide/src/mir-regionck.md index d9d8540814611..571d7c673b7c8 100644 --- a/src/doc/rustc-dev-guide/src/mir-regionck.md +++ b/src/doc/rustc-dev-guide/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 a7a92abfa3dbecc1d7bd65d367fcda9a9025716c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 28 Feb 2018 15:28:57 -0500 Subject: [PATCH 0119/2516] address nits --- src/doc/rustc-dev-guide/src/glossary.md | 2 +- src/doc/rustc-dev-guide/src/mir-regionck.md | 9 +++++---- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 81eb62bc9aeb8..bff2a65572884 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-regionck.md b/src/doc/rustc-dev-guide/src/mir-regionck.md index 571d7c673b7c8..e7b12405af609 100644 --- a/src/doc/rustc-dev-guide/src/mir-regionck.md +++ b/src/doc/rustc-dev-guide/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 09aae098008a8ec1aaa90d254835524d16e36e0b Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 28 Feb 2018 14:40:18 -0600 Subject: [PATCH 0120/2516] Fix funny glossary formatting --- src/doc/rustc-dev-guide/src/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index bff2a65572884..187460f03ad7d 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 984933cec8e46e2478b70553b1b089cc379801f6 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 28 Feb 2018 14:45:51 -0600 Subject: [PATCH 0121/2516] fix table --- src/doc/rustc-dev-guide/src/glossary.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 187460f03ad7d..9c4b66d665917 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 13f99da9d5badcf0674f040a62a55593fe566c00 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 28 Feb 2018 14:58:24 -0600 Subject: [PATCH 0122/2516] actually fix table with hack --- src/doc/rustc-dev-guide/src/glossary.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 9c4b66d665917..7152cba36974c 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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 febe7cb604de94e1d7b63b673b74ed63f62f8f6c Mon Sep 17 00:00:00 2001 From: vishalsodani Date: Thu, 1 Mar 2018 10:04:23 +0530 Subject: [PATCH 0123/2516] Add info about ParseSess for code index #50 --- src/doc/rustc-dev-guide/src/code-index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/code-index.md b/src/doc/rustc-dev-guide/src/code-index.md index 5b452ef0f1102..73e23d8242efc 100644 --- a/src/doc/rustc-dev-guide/src/code-index.md +++ b/src/doc/rustc-dev-guide/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 1f437ef45a248d032abd8b21c7f5ec562afa9439 Mon Sep 17 00:00:00 2001 From: vishalsodani Date: Fri, 2 Mar 2018 09:22:41 +0530 Subject: [PATCH 0124/2516] Add info about CodeMap for #50 --- src/doc/rustc-dev-guide/src/code-index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/code-index.md b/src/doc/rustc-dev-guide/src/code-index.md index 73e23d8242efc..bbfc233e8bfd2 100644 --- a/src/doc/rustc-dev-guide/src/code-index.md +++ b/src/doc/rustc-dev-guide/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 93453e4b45c5c5c165a43234cd44b0846e5052a3 Mon Sep 17 00:00:00 2001 From: vishalsodani Date: Fri, 2 Mar 2018 11:03:20 +0530 Subject: [PATCH 0125/2516] Add info about TraitDef for #50 --- src/doc/rustc-dev-guide/src/code-index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/code-index.md b/src/doc/rustc-dev-guide/src/code-index.md index bbfc233e8bfd2..07aad732c4768 100644 --- a/src/doc/rustc-dev-guide/src/code-index.md +++ b/src/doc/rustc-dev-guide/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 4b0a1f490731e90d7be2cf1cc4ead0e89dce623c Mon Sep 17 00:00:00 2001 From: vishalsodani Date: Fri, 2 Mar 2018 19:42:26 +0530 Subject: [PATCH 0126/2516] keep alphabetical order --- src/doc/rustc-dev-guide/src/code-index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/code-index.md b/src/doc/rustc-dev-guide/src/code-index.md index 07aad732c4768..b1eb3546aa8e8 100644 --- a/src/doc/rustc-dev-guide/src/code-index.md +++ b/src/doc/rustc-dev-guide/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 d58961b4c3d3f1d7055d738626ed2b352e5e15aa Mon Sep 17 00:00:00 2001 From: Michal 'vorner' Vaner Date: Sun, 18 Feb 2018 18:03:46 +0100 Subject: [PATCH 0127/2516] Second pass of name resolution Just small little tweaks --- src/doc/rustc-dev-guide/src/name-resolution.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 25ce3e29eb969..5095b750abdf6 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 e34516461faf8e379bb6b1a3a2712fd2e7964d02 Mon Sep 17 00:00:00 2001 From: Phlosioneer Date: Tue, 6 Mar 2018 20:01:09 -0500 Subject: [PATCH 0128/2516] Fix typo in conventions.md --- src/doc/rustc-dev-guide/src/conventions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index f7ef86f11468c..db531c58c8901 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 8934b148b0351cf4ac7f8ee94e334f2219b814b7 Mon Sep 17 00:00:00 2001 From: "Adam C. Foltzer" Date: Mon, 5 Mar 2018 12:18:33 -0800 Subject: [PATCH 0129/2516] Fix typos --- src/doc/rustc-dev-guide/src/incremental-compilation.md | 2 +- src/doc/rustc-dev-guide/src/query.md | 2 +- src/doc/rustc-dev-guide/src/trait-resolution.md | 4 ++-- src/doc/rustc-dev-guide/src/type-inference.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/incremental-compilation.md b/src/doc/rustc-dev-guide/src/incremental-compilation.md index dc4d06c6c3532..6f5b48cca5183 100644 --- a/src/doc/rustc-dev-guide/src/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 481b4fed3c8b5..33d2b3bacb8bf 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index 1cad488ac5eb0..28176d7401ea3 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index c4307ce7f252c..8812d34d738d0 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 1507b450bea6839994cb4150a99cfd8f0e700c89 Mon Sep 17 00:00:00 2001 From: vishalsodani Date: Sat, 3 Mar 2018 09:58:45 +0530 Subject: [PATCH 0130/2516] Add info about StringReader for #50 --- src/doc/rustc-dev-guide/src/code-index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/code-index.md b/src/doc/rustc-dev-guide/src/code-index.md index b1eb3546aa8e8..2395feaf684ce 100644 --- a/src/doc/rustc-dev-guide/src/code-index.md +++ b/src/doc/rustc-dev-guide/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 7a108324962fa22fca9bc6787456be6baf9b6c73 Mon Sep 17 00:00:00 2001 From: Vishal Sodani Date: Fri, 9 Mar 2018 13:52:57 +0530 Subject: [PATCH 0131/2516] Better explanation for StringReader --- src/doc/rustc-dev-guide/src/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/code-index.md b/src/doc/rustc-dev-guide/src/code-index.md index 2395feaf684ce..6a500abba68c3 100644 --- a/src/doc/rustc-dev-guide/src/code-index.md +++ b/src/doc/rustc-dev-guide/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 e200cf8dce6f0b90bd2a5ba13e67a4ba134195e1 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 27 Feb 2018 05:50:43 -0500 Subject: [PATCH 0132/2516] work on traits chapters --- src/doc/rustc-dev-guide/src/SUMMARY.md | 13 +- .../rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-regions.md | 3 + src/doc/rustc-dev-guide/src/traits-wf.md | 11 + src/doc/rustc-dev-guide/src/traits.md | 18 ++ src/doc/rustc-dev-guide/src/type-inference.md | 2 + 12 files changed, 912 insertions(+), 3 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/traits-associated-types.md create mode 100644 src/doc/rustc-dev-guide/src/traits-bibliography.md create mode 100644 src/doc/rustc-dev-guide/src/traits-canonicalization.md create mode 100644 src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md create mode 100644 src/doc/rustc-dev-guide/src/traits-lowering-rules.md create mode 100644 src/doc/rustc-dev-guide/src/traits-lowering-to-logic.md create mode 100644 src/doc/rustc-dev-guide/src/traits-regions.md create mode 100644 src/doc/rustc-dev-guide/src/traits-wf.md create mode 100644 src/doc/rustc-dev-guide/src/traits.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index ab9da7295c63f..1c5bc284d5c6d 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index 28176d7401ea3..cccfcd54b84e4 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-associated-types.md b/src/doc/rustc-dev-guide/src/traits-associated-types.md new file mode 100644 index 0000000000000..a640bf032bc08 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-bibliography.md b/src/doc/rustc-dev-guide/src/traits-bibliography.md new file mode 100644 index 0000000000000..d9ff912c7b1fc --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md new file mode 100644 index 0000000000000..35352d60528df --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md new file mode 100644 index 0000000000000..ad1655726991d --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-rules.md b/src/doc/rustc-dev-guide/src/traits-lowering-rules.md new file mode 100644 index 0000000000000..d096b4364282b --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits-lowering-to-logic.md new file mode 100644 index 0000000000000..7b1c2ed6b8af7 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-regions.md b/src/doc/rustc-dev-guide/src/traits-regions.md new file mode 100644 index 0000000000000..baa3582b639b8 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/traits-regions.md @@ -0,0 +1,3 @@ +# Region constraints + +*to be written* diff --git a/src/doc/rustc-dev-guide/src/traits-wf.md b/src/doc/rustc-dev-guide/src/traits-wf.md new file mode 100644 index 0000000000000..c002b8cc17be5 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits.md b/src/doc/rustc-dev-guide/src/traits.md new file mode 100644 index 0000000000000..28e27e82eb24b --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 8812d34d738d0..3795ea70ef91b 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 0dbe7e95f726ec63285fc58fe94a3c008d796ff4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 9 Mar 2018 04:14:18 -0500 Subject: [PATCH 0133/2516] clarify how there are two traits chapters --- src/doc/rustc-dev-guide/src/trait-resolution.md | 2 +- src/doc/rustc-dev-guide/src/traits.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index cccfcd54b84e4..d6edcf68a9439 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits.md b/src/doc/rustc-dev-guide/src/traits.md index 28e27e82eb24b..0098704d87553 100644 --- a/src/doc/rustc-dev-guide/src/traits.md +++ b/src/doc/rustc-dev-guide/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 b0802ba5b4a630c2e9b2eb639cfe148f83a0ca03 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 9 Mar 2018 04:16:34 -0500 Subject: [PATCH 0134/2516] link to traits working group tracking issue --- src/doc/rustc-dev-guide/src/traits.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits.md b/src/doc/rustc-dev-guide/src/traits.md index 0098704d87553..f0e67ffd41f00 100644 --- a/src/doc/rustc-dev-guide/src/traits.md +++ b/src/doc/rustc-dev-guide/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 2c4cca82435b4b3f98c9af89550a306a2ca7425a Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 9 Mar 2018 04:19:36 -0500 Subject: [PATCH 0135/2516] don't say 'thing' --- .../src/traits-canonicalization.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index 35352d60528df..8ab73a7ffa0c6 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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 9e4834b65bee7df5c5d2fa0f6148fda7e6d095eb Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 9 Mar 2018 04:30:48 -0500 Subject: [PATCH 0136/2516] expand reorder topic list slightly --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- .../src/traits-canonicalization.md | 5 +++-- src/doc/rustc-dev-guide/src/traits.md | 22 ++++++++++++++----- 3 files changed, 20 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 1c5bc284d5c6d..9c1920d321c48 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index 8ab73a7ffa0c6..9b71c84708326 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits.md b/src/doc/rustc-dev-guide/src/traits.md index f0e67ffd41f00..18cb0c649eff2 100644 --- a/src/doc/rustc-dev-guide/src/traits.md +++ b/src/doc/rustc-dev-guide/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 12188573ce9ea1fb84217d6176cb1af7effa2f9c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 05:32:47 -0500 Subject: [PATCH 0137/2516] add background material on trait queries --- src/doc/rustc-dev-guide/src/SUMMARY.md | 8 +- .../src/traits-canonical-queries.md | 228 ++++++++++++++++++ .../src/traits-canonicalization.md | 7 +- src/doc/rustc-dev-guide/src/traits-slg.md | 1 + src/doc/rustc-dev-guide/src/traits.md | 2 +- 5 files changed, 241 insertions(+), 5 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/traits-canonical-queries.md create mode 100644 src/doc/rustc-dev-guide/src/traits-slg.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 9c1920d321c48..95a5ee577aa15 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonical-queries.md b/src/doc/rustc-dev-guide/src/traits-canonical-queries.md new file mode 100644 index 0000000000000..ec861eb4707fb --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index 9b71c84708326..94b1d6b85801b 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-slg.md b/src/doc/rustc-dev-guide/src/traits-slg.md new file mode 100644 index 0000000000000..cdd52ece953f1 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/traits-slg.md @@ -0,0 +1 @@ +# The SLG solver diff --git a/src/doc/rustc-dev-guide/src/traits.md b/src/doc/rustc-dev-guide/src/traits.md index 18cb0c649eff2..6994f33d2cbb4 100644 --- a/src/doc/rustc-dev-guide/src/traits.md +++ b/src/doc/rustc-dev-guide/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 8c2eddbc5ce77a713b1dfbf7f5da4bad9519c558 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 05:45:36 -0500 Subject: [PATCH 0138/2516] update for notation --- src/doc/rustc-dev-guide/src/traits-canonicalization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index 94b1d6b85801b..db2f939f6ed6f 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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 0fb86c4f8ec1a22d2985f00fe8041be95c466543 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 06:44:29 -0500 Subject: [PATCH 0139/2516] 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/doc/rustc-dev-guide/src/traits-canonical-queries.md b/src/doc/rustc-dev-guide/src/traits-canonical-queries.md index ec861eb4707fb..ee66a73dbdd52 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index db2f939f6ed6f..fc55fac0d4ecc 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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 e561c6ee304a06efc805eb5a618c2b67baef4f46 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 07:04:16 -0500 Subject: [PATCH 0140/2516] numerous edits --- src/doc/rustc-dev-guide/src/SUMMARY.md | 6 ++-- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 95a5ee577aa15..6612372be14e7 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/glossary.md index 7152cba36974c..e542d4e352cd1 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-associated-types.md b/src/doc/rustc-dev-guide/src/traits-associated-types.md index a640bf032bc08..6ac3fc5123d4f 100644 --- a/src/doc/rustc-dev-guide/src/traits-associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md index ad1655726991d..92e1b67d90e0c 100644 --- a/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-rules.md b/src/doc/rustc-dev-guide/src/traits-lowering-rules.md index d096b4364282b..46827dce5a5ea 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-rules.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits-lowering-to-logic.md index 7b1c2ed6b8af7..4e4e7cae9b99f 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-to-logic.md +++ b/src/doc/rustc-dev-guide/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 54700a690d9446a8e2d78e1341b578a80f604780 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 07:06:36 -0500 Subject: [PATCH 0141/2516] add implied bounds placeholder --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/traits-implied-bounds.md | 9 +++++++++ 2 files changed, 10 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/traits-implied-bounds.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 6612372be14e7..8aa450b7b5601 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-implied-bounds.md b/src/doc/rustc-dev-guide/src/traits-implied-bounds.md new file mode 100644 index 0000000000000..26a63bf327162 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 534e9097e2f7b02d54a3a3325625f82999edc142 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 07:09:25 -0500 Subject: [PATCH 0142/2516] update the summary landing page --- src/doc/rustc-dev-guide/src/traits.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits.md b/src/doc/rustc-dev-guide/src/traits.md index 6994f33d2cbb4..b75e7fec682ef 100644 --- a/src/doc/rustc-dev-guide/src/traits.md +++ b/src/doc/rustc-dev-guide/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 1f3267dd2a2a6033d8d67642bf134ec5917afb6b Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 07:10:44 -0500 Subject: [PATCH 0143/2516] fix link --- src/doc/rustc-dev-guide/src/traits.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits.md b/src/doc/rustc-dev-guide/src/traits.md index b75e7fec682ef..175e6418b0866 100644 --- a/src/doc/rustc-dev-guide/src/traits.md +++ b/src/doc/rustc-dev-guide/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 286d5ecaa10b1e23b7dd5ebaaaa049e447819693 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 07:11:11 -0500 Subject: [PATCH 0144/2516] trailing whitespace --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 8aa450b7b5601..d4ee59abf13be 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 4487e00d6ded22a1352c7ef05927c6c9a7d1788d Mon Sep 17 00:00:00 2001 From: Shanavas M Date: Sat, 10 Mar 2018 18:41:11 +0300 Subject: [PATCH 0145/2516] fix typo --- src/doc/rustc-dev-guide/src/tests/intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 8ad2492b76920..eb7294c83427e 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 b1d34cc27de27624f7cb2dd0d1f9aa61164595e5 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 11 Mar 2018 21:05:29 -0500 Subject: [PATCH 0146/2516] Fix a few typos --- .../src/traits-canonical-queries.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits-canonical-queries.md b/src/doc/rustc-dev-guide/src/traits-canonical-queries.md index ee66a73dbdd52..3fea5fbd9787c 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonical-queries.md +++ b/src/doc/rustc-dev-guide/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 d44bc240a0ef8a75f6e8218cbc931bf2c8fc4bf0 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 7 Mar 2018 22:18:05 +0800 Subject: [PATCH 0147/2516] Added a very rough rustc-driver chapter --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/rustc-driver.md | 66 +++++++++++++++++++++ 2 files changed, 67 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/rustc-driver.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index d4ee59abf13be..841a9b4919605 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md new file mode 100644 index 0000000000000..b21cc36622758 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 6159e0298c352e12dc1c8a38555628f7cbc61cbf Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 7 Mar 2018 22:31:22 +0800 Subject: [PATCH 0148/2516] Renamed appendices and added @nrc's guide --- src/doc/rustc-dev-guide/src/SUMMARY.md | 10 +- .../{background.md => appendix-background.md} | 2 +- .../{code-index.md => appendix-code-index.md} | 2 +- .../src/{glossary.md => appendix-glossary.md} | 17 +- .../src/appendix-stupid-stats.md | 396 ++++++++++++++++++ src/doc/rustc-dev-guide/src/mir-borrowck.md | 2 +- src/doc/rustc-dev-guide/src/mir-regionck.md | 8 +- src/doc/rustc-dev-guide/src/mir.md | 2 +- 8 files changed, 419 insertions(+), 20 deletions(-) rename src/doc/rustc-dev-guide/src/{background.md => appendix-background.md} (99%) rename src/doc/rustc-dev-guide/src/{code-index.md => appendix-code-index.md} (98%) rename src/doc/rustc-dev-guide/src/{glossary.md => appendix-glossary.md} (94%) create mode 100644 src/doc/rustc-dev-guide/src/appendix-stupid-stats.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 841a9b4919605..eb889d36be9b4 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/background.md b/src/doc/rustc-dev-guide/src/appendix-background.md similarity index 99% rename from src/doc/rustc-dev-guide/src/background.md rename to src/doc/rustc-dev-guide/src/appendix-background.md index 50c247774e7ba..c69e7d93df5be 100644 --- a/src/doc/rustc-dev-guide/src/background.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/code-index.md b/src/doc/rustc-dev-guide/src/appendix-code-index.md similarity index 98% rename from src/doc/rustc-dev-guide/src/code-index.md rename to src/doc/rustc-dev-guide/src/appendix-code-index.md index 6a500abba68c3..64a40f74d8382 100644 --- a/src/doc/rustc-dev-guide/src/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/glossary.md b/src/doc/rustc-dev-guide/src/appendix-glossary.md similarity index 94% rename from src/doc/rustc-dev-guide/src/glossary.md rename to src/doc/rustc-dev-guide/src/appendix-glossary.md index e542d4e352cd1..1914adec68cbb 100644 --- a/src/doc/rustc-dev-guide/src/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md new file mode 100644 index 0000000000000..405577e3cc7f4 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-borrowck.md b/src/doc/rustc-dev-guide/src/mir-borrowck.md index 3c10191d4c2be..ab99ac9dc7a6f 100644 --- a/src/doc/rustc-dev-guide/src/mir-borrowck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-regionck.md b/src/doc/rustc-dev-guide/src/mir-regionck.md index e7b12405af609..dbf740ea8cfaf 100644 --- a/src/doc/rustc-dev-guide/src/mir-regionck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index 6e7ac06916abe..5c4b163103e9b 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/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 5fd22d349518cfbe19dcb53edf7ded74e0501a62 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 7 Mar 2018 22:32:45 +0800 Subject: [PATCH 0149/2516] Thank you link checker! --- src/doc/rustc-dev-guide/src/mir-borrowck.md | 2 +- src/doc/rustc-dev-guide/src/mir.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir-borrowck.md b/src/doc/rustc-dev-guide/src/mir-borrowck.md index ab99ac9dc7a6f..6c4c99d61dc16 100644 --- a/src/doc/rustc-dev-guide/src/mir-borrowck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index 5c4b163103e9b..688a8750cf3a6 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/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 66bdc602eed3d05eeeccfda69980f5a97164d7c3 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 7 Mar 2018 22:42:27 +0800 Subject: [PATCH 0150/2516] Added a couple definitions to the code index --- src/doc/rustc-dev-guide/src/appendix-code-index.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/appendix-code-index.md b/src/doc/rustc-dev-guide/src/appendix-code-index.md index 64a40f74d8382..2097d61ae1c39 100644 --- a/src/doc/rustc-dev-guide/src/appendix-code-index.md +++ b/src/doc/rustc-dev-guide/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 4ec09356467cc39e59cd3d10192ca3aaaf0b7f98 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Mon, 12 Mar 2018 18:51:08 +0800 Subject: [PATCH 0151/2516] Addressed some of @nrc and @mark-i-m's comments --- .../src/appendix-code-index.md | 23 +++++++++++-------- src/doc/rustc-dev-guide/src/rustc-driver.md | 13 +++++++---- 2 files changed, 23 insertions(+), 13 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-code-index.md b/src/doc/rustc-dev-guide/src/appendix-code-index.md index 2097d61ae1c39..f6dcb9c37ab9a 100644 --- a/src/doc/rustc-dev-guide/src/appendix-code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index b21cc36622758..7e6eb7e2e8d4c 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 9ea5f85b13eaea75d218f21c29dd0c54c46a7b19 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Mon, 12 Mar 2018 19:04:18 +0800 Subject: [PATCH 0152/2516] Updated stupid-stats cc: nrc/stupid-stats#8 --- src/doc/rustc-dev-guide/src/appendix-stupid-stats.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md index 405577e3cc7f4..b1c9d21412255 100644 --- a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md +++ b/src/doc/rustc-dev-guide/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 2498453fccfd0cafd59948ca7497094b280ef536 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Mon, 12 Mar 2018 19:15:06 +0800 Subject: [PATCH 0153/2516] Fixed a broken link --- src/doc/rustc-dev-guide/src/traits-canonicalization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index fc55fac0d4ecc..6ff61fdda9b79 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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 a9c92eba76238a23bb3b571b2af99796e929725d Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Mon, 12 Mar 2018 19:15:26 +0800 Subject: [PATCH 0154/2516] Added links back to nrc's stupid-stats --- src/doc/rustc-dev-guide/src/appendix-stupid-stats.md | 9 ++++++++- src/doc/rustc-dev-guide/src/rustc-driver.md | 7 ++++++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md index b1c9d21412255..20d5aaf9baaca 100644 --- a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 7e6eb7e2e8d4c..23a036e7362b4 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 991a538a795b0627dab9a120109a874dfa37da60 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Mar 2018 12:54:19 -0500 Subject: [PATCH 0155/2516] fix typo --- src/doc/rustc-dev-guide/src/traits-canonicalization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index 6ff61fdda9b79..bef858af22e33 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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 d542f9434352dafca744d10f4afe1e5e283dadfa Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Mar 2018 19:39:56 -0500 Subject: [PATCH 0156/2516] Add the contents of the typeck READMEs --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 + .../src/appendix-background.md | 3 + .../src/appendix-code-index.md | 2 + .../rustc-dev-guide/src/appendix-glossary.md | 3 +- src/doc/rustc-dev-guide/src/method-lookup.md | 119 +++++++ src/doc/rustc-dev-guide/src/type-checking.md | 43 +++ src/doc/rustc-dev-guide/src/variance.md | 296 ++++++++++++++++++ 7 files changed, 467 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/src/method-lookup.md create mode 100644 src/doc/rustc-dev-guide/src/variance.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index eb889d36be9b4..9215f8afaae40 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix-background.md b/src/doc/rustc-dev-guide/src/appendix-background.md index c69e7d93df5be..b49ad6d52fd2e 100644 --- a/src/doc/rustc-dev-guide/src/appendix-background.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix-code-index.md b/src/doc/rustc-dev-guide/src/appendix-code-index.md index f6dcb9c37ab9a..3ca9bfb76150f 100644 --- a/src/doc/rustc-dev-guide/src/appendix-code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix-glossary.md b/src/doc/rustc-dev-guide/src/appendix-glossary.md index 1914adec68cbb..8a3df24e8e0b1 100644 --- a/src/doc/rustc-dev-guide/src/appendix-glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/method-lookup.md b/src/doc/rustc-dev-guide/src/method-lookup.md new file mode 100644 index 0000000000000..543428d621a49 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-checking.md b/src/doc/rustc-dev-guide/src/type-checking.md index c559c1283600f..8148ef627972e 100644 --- a/src/doc/rustc-dev-guide/src/type-checking.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md new file mode 100644 index 0000000000000..16b4a7518379c --- /dev/null +++ b/src/doc/rustc-dev-guide/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 4d441fd6d6b26e4d9fada8c9f74e1bf000d12443 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Mar 2018 19:50:43 -0500 Subject: [PATCH 0157/2516] Add the rustdoc readme --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/rustdoc.md | 177 +++++++++++++++++++++++++ 2 files changed, 178 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/rustdoc.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 9215f8afaae40..3079c0b48acc7 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md new file mode 100644 index 0000000000000..4236ad6ff269e --- /dev/null +++ b/src/doc/rustc-dev-guide/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 d9bbf17bba4778a7eb19219dc5d9a531e2897334 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 14 Mar 2018 22:08:09 -0500 Subject: [PATCH 0158/2516] Address review comments --- .../src/appendix-code-index.md | 1 + src/doc/rustc-dev-guide/src/rustdoc.md | 44 ++++++++++++++++--- 2 files changed, 39 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-code-index.md b/src/doc/rustc-dev-guide/src/appendix-code-index.md index 3ca9bfb76150f..c5be7e336e736 100644 --- a/src/doc/rustc-dev-guide/src/appendix-code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 4236ad6ff269e..2cacc80fda8e7 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 821fb082902cc1dcde4e7fb8a066bcefe825bf9a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 15 Mar 2018 09:38:50 -0500 Subject: [PATCH 0159/2516] address review comments --- .../rustc-dev-guide/src/appendix-code-index.md | 1 + src/doc/rustc-dev-guide/src/rustdoc.md | 17 +++++++++++------ 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-code-index.md b/src/doc/rustc-dev-guide/src/appendix-code-index.md index c5be7e336e736..49fe08ee30149 100644 --- a/src/doc/rustc-dev-guide/src/appendix-code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 2cacc80fda8e7..bb4122e8dfc9b 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 4200ed55efbcfc3f7039c1d2f3c182463417d9a7 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 15 Mar 2018 12:46:59 -0500 Subject: [PATCH 0160/2516] Updated parenthetical --- src/doc/rustc-dev-guide/src/rustdoc.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index bb4122e8dfc9b..ae640d11070d9 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 27d1918c071c33abb9fc8072d7ab4a7d80b882e3 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 15 Mar 2018 14:26:09 -0400 Subject: [PATCH 0161/2516] 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/doc/rustc-dev-guide/src/traits-lowering-rules.md b/src/doc/rustc-dev-guide/src/traits-lowering-rules.md index 46827dce5a5ea..8de20f1d8417e 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-rules.md +++ b/src/doc/rustc-dev-guide/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 93cf9a80068a22b621490849f081d29ffe28e89c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 16 Mar 2018 11:45:09 -0500 Subject: [PATCH 0162/2516] Add incremental compilation debugging subchapter --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../rustc-dev-guide/src/incrcomp-debugging.md | 113 ++++++++++++++++++ 2 files changed, 114 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/incrcomp-debugging.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 3079c0b48acc7..47775e29c87ef 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/incrcomp-debugging.md b/src/doc/rustc-dev-guide/src/incrcomp-debugging.md new file mode 100644 index 0000000000000..92a8e10ea3cc5 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 64188bd8ada272d09a54ef9efbbc8d65348fb331 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 19 Mar 2018 10:50:43 -0400 Subject: [PATCH 0163/2516] describe how the lowering code works --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/traits-lowering-module.md | 66 +++++++++++++++++++ 2 files changed, 67 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/traits-lowering-module.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 47775e29c87ef..da84350ea8f92 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-module.md b/src/doc/rustc-dev-guide/src/traits-lowering-module.md new file mode 100644 index 0000000000000..c47b8fbe84530 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 25aab56909bd7c7f96006204e9bb9bd05593ab97 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 19 Mar 2018 10:56:51 -0400 Subject: [PATCH 0164/2516] bump mdbook to 0.1.5 --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index a5d87a6bc3b2f..0a36ff1f9e6f1 100644 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 e4227c5cfd1da1365d19cb3889d1062ff944f5d0 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 16 Mar 2018 10:39:12 -0700 Subject: [PATCH 0165/2516] Add mdbook search. --- src/doc/rustc-dev-guide/book.toml | 2 ++ src/doc/rustc-dev-guide/ci/install.sh | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 3c4c537e8b322..f3a192c678444 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/book.toml @@ -6,3 +6,5 @@ description = "A guide to developing rustc " [output.html] [output.linkcheck] + +[output.html.search] diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 0a36ff1f9e6f1..975857a95a086 100644 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 af52f35b46ba2f9e61e2d4dc6329d4475deb2e9d Mon Sep 17 00:00:00 2001 From: Dan Robertson Date: Sun, 25 Mar 2018 13:50:58 +0000 Subject: [PATCH 0166/2516] Minor grammar and syntax fixes Minor grammar and syntax fixes found while reading. --- src/doc/rustc-dev-guide/src/trait-caching.md | 4 +++- src/doc/rustc-dev-guide/src/traits-associated-types.md | 10 ++++++---- src/doc/rustc-dev-guide/src/type-inference.md | 2 +- 3 files changed, 10 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/trait-caching.md b/src/doc/rustc-dev-guide/src/trait-caching.md index ee92814cdba12..4c728d52164b3 100644 --- a/src/doc/rustc-dev-guide/src/trait-caching.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-associated-types.md b/src/doc/rustc-dev-guide/src/traits-associated-types.md index 6ac3fc5123d4f..c91dc255fe413 100644 --- a/src/doc/rustc-dev-guide/src/traits-associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 3795ea70ef91b..c7a9c2b635b13 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 85a834b74b30aac00ed81cf2971c554621d7275a Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Fri, 23 Feb 2018 21:07:36 +0000 Subject: [PATCH 0167/2516] Added EditorConfig file for `src`. --- src/doc/rustc-dev-guide/.editorconfig | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 src/doc/rustc-dev-guide/.editorconfig diff --git a/src/doc/rustc-dev-guide/.editorconfig b/src/doc/rustc-dev-guide/.editorconfig new file mode 100644 index 0000000000000..cb3312517e2fd --- /dev/null +++ b/src/doc/rustc-dev-guide/.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 5f4e24d4ec123c5ea79f4e3c8f7b56c77ee29788 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Fri, 23 Feb 2018 21:51:29 +0000 Subject: [PATCH 0168/2516] Added check for all source files to ensure they have no lines longer than 80 chars. --- src/doc/rustc-dev-guide/.travis.yml | 2 ++ .../rustc-dev-guide/ci/check_line_lengths.sh | 19 +++++++++++++++++++ src/doc/rustc-dev-guide/ci/install.sh | 1 + 3 files changed, 22 insertions(+) create mode 100755 src/doc/rustc-dev-guide/ci/check_line_lengths.sh mode change 100644 => 100755 src/doc/rustc-dev-guide/ci/install.sh diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 5ca97ba79df17..da9c1ed0aa1af 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/check_line_lengths.sh b/src/doc/rustc-dev-guide/ci/check_line_lengths.sh new file mode 100755 index 0000000000000..8001ea9a7c326 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh old mode 100644 new mode 100755 index 975857a95a086..ea90e853dfabc --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/ci/install.sh @@ -1,4 +1,5 @@ #!/bin/bash + set -ex function cargo_install() { From b5bd9cbb9b8b2228858808dd674626f6cac8b05e Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sat, 24 Feb 2018 01:43:36 +0000 Subject: [PATCH 0169/2516] Ignore line check on certain types of lines or in certain blocks. --- src/doc/rustc-dev-guide/ci/check_line_lengths.sh | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh b/src/doc/rustc-dev-guide/ci/check_line_lengths.sh index 8001ea9a7c326..27711806a0f13 100755 --- a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh +++ b/src/doc/rustc-dev-guide/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 fd04912abdfeb3b2a93eef736a4d9e6797e90ea9 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sat, 24 Feb 2018 01:43:53 +0000 Subject: [PATCH 0170/2516] Hard-wrapped lines that are too long. --- .../rustc-dev-guide/ci/check_line_lengths.sh | 2 +- src/doc/rustc-dev-guide/src/SUMMARY.md | 3 +- src/doc/rustc-dev-guide/src/compiletest.md | 30 ++++----- .../src/high-level-overview.md | 29 ++++----- src/doc/rustc-dev-guide/src/hir.md | 38 ++++++------ .../src/how-to-build-and-run.md | 34 +++++----- .../src/incremental-compilation.md | 39 ++++++------ src/doc/rustc-dev-guide/src/query.md | 12 ++-- src/doc/rustc-dev-guide/src/tests/adding.md | 62 ++++++++++++------- src/doc/rustc-dev-guide/src/tests/intro.md | 39 ++++++------ src/doc/rustc-dev-guide/src/tests/running.md | 9 +-- src/doc/rustc-dev-guide/src/trait-hrtb.md | 8 ++- .../rustc-dev-guide/src/trait-resolution.md | 28 +++++---- src/doc/rustc-dev-guide/src/ty.md | 17 ++--- src/doc/rustc-dev-guide/src/type-inference.md | 17 ++--- 15 files changed, 206 insertions(+), 161 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh b/src/doc/rustc-dev-guide/ci/check_line_lengths.sh index 27711806a0f13..b32906da68feb 100755 --- a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index da84350ea8f92..3460d949d5bdb 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index f07d3065a425e..0cfc6b39d17ad 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 493656713a75e..041136548308f 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 41ed0ab206e5b..f66468ffc4c8e 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 7b6088c7c0ea1..6e292934b3b4d 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/incremental-compilation.md b/src/doc/rustc-dev-guide/src/incremental-compilation.md index 6f5b48cca5183..a209207fca220 100644 --- a/src/doc/rustc-dev-guide/src/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 33d2b3bacb8bf..500b9dec8783e 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 276189f59c8c8..f777a458c8e24 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index eb7294c83427e..e8cf34aff7765 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 98d590671c93b..6bac0121a038b 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-hrtb.md b/src/doc/rustc-dev-guide/src/trait-hrtb.md index 8c3a6f4e969c6..d677db2c5fc1a 100644 --- a/src/doc/rustc-dev-guide/src/trait-hrtb.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index d6edcf68a9439..7494d969a3b2f 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 26b8c1ca8ff49..1fd86a6bd898e 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index c7a9c2b635b13..45f9df18afb4f 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 593e6d361ff419afc56a2a594675b03bfde6e6d0 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 20 Mar 2018 09:48:17 -0400 Subject: [PATCH 0171/2516] make the script give more useful feedback --- src/doc/rustc-dev-guide/ci/check_line_lengths.sh | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh b/src/doc/rustc-dev-guide/ci/check_line_lengths.sh index b32906da68feb..dc48091c87334 100755 --- a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh +++ b/src/doc/rustc-dev-guide/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 cde5c6586dc24ff19553389981fe9cb7227a0038 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Thu, 22 Mar 2018 02:05:28 +0000 Subject: [PATCH 0172/2516] Travis CI script now sets `globstar` shell option. --- src/doc/rustc-dev-guide/.travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index da9c1ed0aa1af..45ba4a8903165 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 03577700d000de311c8f1570fe03b59afac36e28 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Mar 2018 20:56:05 -0500 Subject: [PATCH 0173/2516] Fix long lines in glossary --- src/doc/rustc-dev-guide/src/appendix-glossary.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-glossary.md b/src/doc/rustc-dev-guide/src/appendix-glossary.md index 8a3df24e8e0b1..1d82686ba9265 100644 --- a/src/doc/rustc-dev-guide/src/appendix-glossary.md +++ b/src/doc/rustc-dev-guide/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 56119dca19a6cf3f30c3b066194eb353508979e2 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Mar 2018 20:57:17 -0500 Subject: [PATCH 0174/2516] Fix long lines in stupid stats appendix --- src/doc/rustc-dev-guide/src/appendix-stupid-stats.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md index 20d5aaf9baaca..8e50b2c315ea6 100644 --- a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md +++ b/src/doc/rustc-dev-guide/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 81d0be49b3f8f8ab7781d77b7d2964c471de54a0 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Mar 2018 21:01:59 -0500 Subject: [PATCH 0175/2516] Fix long lines in compiletest --- src/doc/rustc-dev-guide/src/compiletest.md | 175 ++++++++++++++------- 1 file changed, 114 insertions(+), 61 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 0cfc6b39d17ad..011304d450bbd 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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 2a1f1e33b2cf6cc5b1a4a11953853540108cda40 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Mar 2018 21:02:33 -0500 Subject: [PATCH 0176/2516] Fix long lines in const-eval --- src/doc/rustc-dev-guide/src/const-eval.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/const-eval.md b/src/doc/rustc-dev-guide/src/const-eval.md index 3fb65216afe5f..4a05255c6f73e 100644 --- a/src/doc/rustc-dev-guide/src/const-eval.md +++ b/src/doc/rustc-dev-guide/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 89f103c75c13ef8477d710da3e46b527417a29e3 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Mar 2018 21:03:13 -0500 Subject: [PATCH 0177/2516] Fix long lines in conventions --- src/doc/rustc-dev-guide/src/conventions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index db531c58c8901..96571301ffef1 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 b15068a58fca526985b91ae752091ac89480d2fb Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 26 Mar 2018 10:41:14 -0500 Subject: [PATCH 0178/2516] More long lines --- .../rustc-dev-guide/src/incrcomp-debugging.md | 8 ++--- src/doc/rustc-dev-guide/src/mir-borrowck.md | 9 +++-- src/doc/rustc-dev-guide/src/mir-passes.md | 22 +++++++----- src/doc/rustc-dev-guide/src/mir-regionck.md | 35 +++++++++---------- src/doc/rustc-dev-guide/src/mir.md | 25 +++++++------ 5 files changed, 55 insertions(+), 44 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/incrcomp-debugging.md b/src/doc/rustc-dev-guide/src/incrcomp-debugging.md index 92a8e10ea3cc5..261b46eb0ebb5 100644 --- a/src/doc/rustc-dev-guide/src/incrcomp-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-borrowck.md b/src/doc/rustc-dev-guide/src/mir-borrowck.md index 6c4c99d61dc16..51a6c6cbf2692 100644 --- a/src/doc/rustc-dev-guide/src/mir-borrowck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-passes.md b/src/doc/rustc-dev-guide/src/mir-passes.md index 6d657ae70744f..cd05edfb870e1 100644 --- a/src/doc/rustc-dev-guide/src/mir-passes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-regionck.md b/src/doc/rustc-dev-guide/src/mir-regionck.md index dbf740ea8cfaf..529b423957296 100644 --- a/src/doc/rustc-dev-guide/src/mir-regionck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index 688a8750cf3a6..58479cf961e15 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/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 8901200fab817a0c8ae97df55801123c33dea41e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 26 Mar 2018 10:44:32 -0500 Subject: [PATCH 0179/2516] 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/doc/rustc-dev-guide/src/traits-canonical-queries.md b/src/doc/rustc-dev-guide/src/traits-canonical-queries.md index 3fea5fbd9787c..b291a289887b0 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index bef858af22e33..9f3af36c97a29 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md index 92e1b67d90e0c..8e5e82d011eae 100644 --- a/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-rules.md b/src/doc/rustc-dev-guide/src/traits-lowering-rules.md index 8de20f1d8417e..544ae41b30097 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-rules.md +++ b/src/doc/rustc-dev-guide/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 ae62bb6cf46386e5c593ecf51557d154c22761c6 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 26 Mar 2018 10:46:39 -0500 Subject: [PATCH 0180/2516] reformat basically the whole rustdoc.md --- src/doc/rustc-dev-guide/src/rustdoc.md | 293 ++++++++++++++----------- 1 file changed, 162 insertions(+), 131 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index ae640d11070d9..7a9905d3b1177 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 8c7b06d3cbc78f02ae0c3906f8b8e57c8aeb2daf 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 0181/2516] Add info on test result caching --- src/doc/rustc-dev-guide/src/tests/running.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 6bac0121a038b..84cead4bf57b1 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 76a80349e9a57bcb8487f815ab9b3189d53a6218 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 0182/2516] Fix a typo --- src/doc/rustc-dev-guide/src/tests/running.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 84cead4bf57b1..4e8c71590322d 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 bf92dda27f8a503fab031a3411bfafe4cfc23032 Mon Sep 17 00:00:00 2001 From: Dan Robertson Date: Wed, 28 Mar 2018 03:23:51 +0000 Subject: [PATCH 0183/2516] Update links Add missing link and add link for UFCS. --- src/doc/rustc-dev-guide/src/method-lookup.md | 3 ++- src/doc/rustc-dev-guide/src/traits-bibliography.md | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/method-lookup.md b/src/doc/rustc-dev-guide/src/method-lookup.md index 543428d621a49..ac0e427db6f1b 100644 --- a/src/doc/rustc-dev-guide/src/method-lookup.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-bibliography.md b/src/doc/rustc-dev-guide/src/traits-bibliography.md index d9ff912c7b1fc..02607b525b188 100644 --- a/src/doc/rustc-dev-guide/src/traits-bibliography.md +++ b/src/doc/rustc-dev-guide/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 80fd9ba1b61f215555a16a38b79a1c332a6d6517 Mon Sep 17 00:00:00 2001 From: Philip Munksgaard Date: Tue, 3 Apr 2018 16:27:29 +0200 Subject: [PATCH 0184/2516] Fix typo in rustdoc.md --- src/doc/rustc-dev-guide/src/rustdoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 7a9905d3b1177..e075087fcbb12 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 344c194ec347baffe8aa80cc7f1ad9ff0e43f928 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Wed, 4 Apr 2018 13:41:23 -0400 Subject: [PATCH 0185/2516] Link to internal rustdocs#100 --- src/doc/rustc-dev-guide/src/appendix-stupid-stats.md | 2 +- src/doc/rustc-dev-guide/src/macro-expansion.md | 6 +++--- src/doc/rustc-dev-guide/src/mir-passes.md | 4 ++-- src/doc/rustc-dev-guide/src/mir-visitor.md | 6 +++--- src/doc/rustc-dev-guide/src/query.md | 4 ++-- src/doc/rustc-dev-guide/src/rustc-driver.md | 10 +++++----- src/doc/rustc-dev-guide/src/the-parser.md | 10 +++++----- src/doc/rustc-dev-guide/src/traits-lowering-module.md | 2 +- 8 files changed, 22 insertions(+), 22 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md index 8e50b2c315ea6..7aef3a87b7895 100644 --- a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 95ea64f191546..c55fdd1366abf 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-passes.md b/src/doc/rustc-dev-guide/src/mir-passes.md index cd05edfb870e1..1d1e27df4c6f3 100644 --- a/src/doc/rustc-dev-guide/src/mir-passes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-visitor.md b/src/doc/rustc-dev-guide/src/mir-visitor.md index 3a8b06c543a02..d8b3af497f57a 100644 --- a/src/doc/rustc-dev-guide/src/mir-visitor.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 500b9dec8783e..e3c55404919fa 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 23a036e7362b4..af3c3c099dfed 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index 456f0a9eaa7a9..623a38e672a67 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-module.md b/src/doc/rustc-dev-guide/src/traits-lowering-module.md index c47b8fbe84530..27c4f29bcb1a5 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-module.md +++ b/src/doc/rustc-dev-guide/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 4cc0e598df844887a8a90ac07408e7bab1c1c1b3 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 5 Apr 2018 08:52:55 -0400 Subject: [PATCH 0186/2516] link directly to the compile-input function --- src/doc/rustc-dev-guide/src/appendix-stupid-stats.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md index 7aef3a87b7895..87e2ba6dcd637 100644 --- a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md +++ b/src/doc/rustc-dev-guide/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 75c260635b7d09631d202ffe4c620e9206c2b683 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 5 Apr 2018 15:24:38 -0400 Subject: [PATCH 0187/2516] 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/doc/rustc-dev-guide/src/appendix-code-index.md b/src/doc/rustc-dev-guide/src/appendix-code-index.md index 49fe08ee30149..62edd0f5b1cdc 100644 --- a/src/doc/rustc-dev-guide/src/appendix-code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md index 87e2ba6dcd637..91da6d2a8a710 100644 --- a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md +++ b/src/doc/rustc-dev-guide/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 feb61dadcb58922abf1e4a254afe8134899f485a Mon Sep 17 00:00:00 2001 From: varkor Date: Thu, 5 Apr 2018 13:24:08 +0100 Subject: [PATCH 0188/2516] Consolidate and fix code blocks --- src/doc/rustc-dev-guide/README.md | 4 +- .../src/appendix-background.md | 6 +- .../src/appendix-stupid-stats.md | 16 +- src/doc/rustc-dev-guide/src/compiletest.md | 3 +- src/doc/rustc-dev-guide/src/conventions.md | 6 +- .../src/high-level-overview.md | 2 +- src/doc/rustc-dev-guide/src/hir.md | 4 +- .../src/how-to-build-and-run.md | 8 +- .../rustc-dev-guide/src/incrcomp-debugging.md | 16 +- .../rustc-dev-guide/src/macro-expansion.md | 6 +- src/doc/rustc-dev-guide/src/method-lookup.md | 15 +- src/doc/rustc-dev-guide/src/mir-passes.md | 6 +- src/doc/rustc-dev-guide/src/mir-regionck.md | 206 +++++++++++------- src/doc/rustc-dev-guide/src/mir-visitor.md | 6 +- src/doc/rustc-dev-guide/src/mir.md | 32 +-- src/doc/rustc-dev-guide/src/miri.md | 4 +- src/doc/rustc-dev-guide/src/query.md | 24 +- src/doc/rustc-dev-guide/src/rustdoc.md | 2 +- src/doc/rustc-dev-guide/src/tests/adding.md | 10 +- src/doc/rustc-dev-guide/src/tests/running.md | 18 +- src/doc/rustc-dev-guide/src/trait-caching.md | 2 +- src/doc/rustc-dev-guide/src/trait-hrtb.md | 6 +- .../rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md | 14 +- src/doc/rustc-dev-guide/src/type-checking.md | 4 +- src/doc/rustc-dev-guide/src/type-inference.md | 20 +- src/doc/rustc-dev-guide/src/variance.md | 88 +++++--- 34 files changed, 584 insertions(+), 426 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 7e468fbb0db97..07d1749e8c759 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix-background.md b/src/doc/rustc-dev-guide/src/appendix-background.md index b49ad6d52fd2e..285d74477bb4f 100644 --- a/src/doc/rustc-dev-guide/src/appendix-background.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md index 91da6d2a8a710..0c4de5c7a5dd8 100644 --- a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 011304d450bbd..363c12d3b328f 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 96571301ffef1..89a986789494b 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 041136548308f..e369db28c7b7e 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index f66468ffc4c8e..3d2fbede3c4fe 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 6e292934b3b4d..535823dfd2d24 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/incrcomp-debugging.md b/src/doc/rustc-dev-guide/src/incrcomp-debugging.md index 261b46eb0ebb5..3ad9f3a4969bc 100644 --- a/src/doc/rustc-dev-guide/src/incrcomp-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index c55fdd1366abf..ba807faf28576 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/method-lookup.md b/src/doc/rustc-dev-guide/src/method-lookup.md index ac0e427db6f1b..dbbc62fa8aef6 100644 --- a/src/doc/rustc-dev-guide/src/method-lookup.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-passes.md b/src/doc/rustc-dev-guide/src/mir-passes.md index 1d1e27df4c6f3..fd0c6cca1c613 100644 --- a/src/doc/rustc-dev-guide/src/mir-passes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-regionck.md b/src/doc/rustc-dev-guide/src/mir-regionck.md index 529b423957296..949b11d900593 100644 --- a/src/doc/rustc-dev-guide/src/mir-regionck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-visitor.md b/src/doc/rustc-dev-guide/src/mir-visitor.md index d8b3af497f57a..265769b34c506 100644 --- a/src/doc/rustc-dev-guide/src/mir-visitor.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index 58479cf961e15..8e45a62bc523c 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index 4b0a600bebe93..fb6675f50fcec 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index e3c55404919fa..2c518ee55ee4c 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index e075087fcbb12..36195c3a5625b 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index f777a458c8e24..f97f4a57e1196 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 4e8c71590322d..03eb8ccc48ad4 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-caching.md b/src/doc/rustc-dev-guide/src/trait-caching.md index 4c728d52164b3..4b7d7e096365b 100644 --- a/src/doc/rustc-dev-guide/src/trait-caching.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-hrtb.md b/src/doc/rustc-dev-guide/src/trait-hrtb.md index d677db2c5fc1a..7f77f274cd529 100644 --- a/src/doc/rustc-dev-guide/src/trait-hrtb.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index 7494d969a3b2f..5bf8f8716fc7c 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-associated-types.md b/src/doc/rustc-dev-guide/src/traits-associated-types.md index c91dc255fe413..bcf6b48ea9133 100644 --- a/src/doc/rustc-dev-guide/src/traits-associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonical-queries.md b/src/doc/rustc-dev-guide/src/traits-canonical-queries.md index b291a289887b0..99916267d8be3 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index 9f3af36c97a29..576ca205542fc 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md index 8e5e82d011eae..97532195e4115 100644 --- a/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-module.md b/src/doc/rustc-dev-guide/src/traits-lowering-module.md index 27c4f29bcb1a5..fa068f86a4de3 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-module.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-rules.md b/src/doc/rustc-dev-guide/src/traits-lowering-rules.md index 544ae41b30097..1a9717f9f48be 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-rules.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits-lowering-to-logic.md index 4e4e7cae9b99f..f36794d2c1984 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-to-logic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 1fd86a6bd898e..44017dd5b5f39 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-checking.md b/src/doc/rustc-dev-guide/src/type-checking.md index 8148ef627972e..cca032e308ecb 100644 --- a/src/doc/rustc-dev-guide/src/type-checking.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 45f9df18afb4f..ad399d47b5377 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md index 16b4a7518379c..ea575a5958b53 100644 --- a/src/doc/rustc-dev-guide/src/variance.md +++ b/src/doc/rustc-dev-guide/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 f32d80510c4c11fe66ce65ff6d57132a30c45b59 Mon Sep 17 00:00:00 2001 From: varkor Date: Fri, 6 Apr 2018 19:35:21 +0100 Subject: [PATCH 0189/2516] Replace txt with text --- .../src/appendix-stupid-stats.md | 2 +- .../src/high-level-overview.md | 2 +- .../rustc-dev-guide/src/incrcomp-debugging.md | 10 ++-- src/doc/rustc-dev-guide/src/method-lookup.md | 2 +- src/doc/rustc-dev-guide/src/mir-passes.md | 4 +- src/doc/rustc-dev-guide/src/mir-regionck.md | 52 +++++++++---------- src/doc/rustc-dev-guide/src/mir.md | 4 +- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md | 8 +-- src/doc/rustc-dev-guide/src/variance.md | 18 +++---- 17 files changed, 101 insertions(+), 101 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md index 0c4de5c7a5dd8..9b7d9812b8ac4 100644 --- a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index e369db28c7b7e..9f3b63a549e7b 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/incrcomp-debugging.md b/src/doc/rustc-dev-guide/src/incrcomp-debugging.md index 3ad9f3a4969bc..2488aa320de42 100644 --- a/src/doc/rustc-dev-guide/src/incrcomp-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/method-lookup.md b/src/doc/rustc-dev-guide/src/method-lookup.md index dbbc62fa8aef6..a3d8dca29c056 100644 --- a/src/doc/rustc-dev-guide/src/method-lookup.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-passes.md b/src/doc/rustc-dev-guide/src/mir-passes.md index fd0c6cca1c613..64e72f06e4559 100644 --- a/src/doc/rustc-dev-guide/src/mir-passes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-regionck.md b/src/doc/rustc-dev-guide/src/mir-regionck.md index 949b11d900593..4158b7d38111f 100644 --- a/src/doc/rustc-dev-guide/src/mir-regionck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index 8e45a62bc523c..da468acf42ee1 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index f97f4a57e1196..ab5a0adc13eb4 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-associated-types.md b/src/doc/rustc-dev-guide/src/traits-associated-types.md index bcf6b48ea9133..e2dd94d5a8694 100644 --- a/src/doc/rustc-dev-guide/src/traits-associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonical-queries.md b/src/doc/rustc-dev-guide/src/traits-canonical-queries.md index 99916267d8be3..3c4bb1bfeb2b8 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index 576ca205542fc..cce91a388b103 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md index 97532195e4115..5e8ee1469f584 100644 --- a/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-module.md b/src/doc/rustc-dev-guide/src/traits-lowering-module.md index fa068f86a4de3..cb3b4a5f7e7a6 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-module.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-rules.md b/src/doc/rustc-dev-guide/src/traits-lowering-rules.md index 1a9717f9f48be..f7433221e7889 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-rules.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits-lowering-to-logic.md index f36794d2c1984..54b3473d40d90 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-to-logic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index ad399d47b5377..152bbd9dadac8 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md index ea575a5958b53..5fe84636f21bb 100644 --- a/src/doc/rustc-dev-guide/src/variance.md +++ b/src/doc/rustc-dev-guide/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 8d688c70f3187f0d1da2b616464c68c3d466b36a Mon Sep 17 00:00:00 2001 From: varkor Date: Fri, 6 Apr 2018 19:36:48 +0100 Subject: [PATCH 0190/2516] Fix spacing --- src/doc/rustc-dev-guide/src/traits-canonicalization.md | 4 ++-- src/doc/rustc-dev-guide/src/variance.md | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits-canonicalization.md index cce91a388b103..fa39151d73b59 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md index 5fe84636f21bb..527c2745c8255 100644 --- a/src/doc/rustc-dev-guide/src/variance.md +++ b/src/doc/rustc-dev-guide/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 1a5d5f1e3b092031c34a49cd993200a2652056de Mon Sep 17 00:00:00 2001 From: varkor Date: Fri, 6 Apr 2018 19:39:25 +0100 Subject: [PATCH 0191/2516] Add mdbook test to Travis --- src/doc/rustc-dev-guide/.travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 45ba4a8903165..d7f8f8f42f560 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.travis.yml @@ -9,6 +9,7 @@ install: - bash ci/install.sh script: - mdbook build +- mdbook test notifications: email: on_success: never From 4f8b7e7e2aab209991e73ee68a99019ea5fcd474 Mon Sep 17 00:00:00 2001 From: varkor Date: Fri, 6 Apr 2018 20:04:59 +0100 Subject: [PATCH 0192/2516] Fix unstable Rust code block issue --- src/doc/rustc-dev-guide/src/traits-lowering-module.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits-lowering-module.md b/src/doc/rustc-dev-guide/src/traits-lowering-module.md index cb3b4a5f7e7a6..fbf1d6425d886 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-module.md +++ b/src/doc/rustc-dev-guide/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 0626dc257f8c8eb894b5a84ef3ab1189c0641747 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Fri, 6 Apr 2018 20:58:37 -0400 Subject: [PATCH 0193/2516] update nightly documention for issue#100-b --- src/doc/rustc-dev-guide/src/appendix-stupid-stats.md | 2 +- src/doc/rustc-dev-guide/src/const-eval.md | 2 +- src/doc/rustc-dev-guide/src/method-lookup.md | 4 ++-- src/doc/rustc-dev-guide/src/miri.md | 2 +- src/doc/rustc-dev-guide/src/type-checking.md | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md index 9b7d9812b8ac4..842a2a3286a66 100644 --- a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/const-eval.md b/src/doc/rustc-dev-guide/src/const-eval.md index 4a05255c6f73e..70c946f176a68 100644 --- a/src/doc/rustc-dev-guide/src/const-eval.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/method-lookup.md b/src/doc/rustc-dev-guide/src/method-lookup.md index a3d8dca29c056..5aafb6abf04e3 100644 --- a/src/doc/rustc-dev-guide/src/method-lookup.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index fb6675f50fcec..be9587408ceac 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-checking.md b/src/doc/rustc-dev-guide/src/type-checking.md index cca032e308ecb..cb6d346e4c2c5 100644 --- a/src/doc/rustc-dev-guide/src/type-checking.md +++ b/src/doc/rustc-dev-guide/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 9af854341c82c07e94848171629dcad5a409f81d Mon Sep 17 00:00:00 2001 From: QuietMisdreavus Date: Tue, 10 Apr 2018 19:45:46 -0500 Subject: [PATCH 0194/2516] talk about `only-X` in compiletest --- src/doc/rustc-dev-guide/src/tests/adding.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index ab5a0adc13eb4..1445981ebc4e9 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 5ddeec28e3b86e7b14aa52d2b0c950aaf67d7581 Mon Sep 17 00:00:00 2001 From: Samuel Wilson Date: Sat, 7 Apr 2018 00:01:51 +1200 Subject: [PATCH 0195/2516] 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/doc/rustc-dev-guide/src/appendix-glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix-glossary.md b/src/doc/rustc-dev-guide/src/appendix-glossary.md index 1d82686ba9265..23de529f2fa7d 100644 --- a/src/doc/rustc-dev-guide/src/appendix-glossary.md +++ b/src/doc/rustc-dev-guide/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 7d54f2aaa860930d4b3bea0cc37086357bcc5bd7 Mon Sep 17 00:00:00 2001 From: Samuel Wilson Date: Sat, 7 Apr 2018 00:01:51 +1200 Subject: [PATCH 0196/2516] 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/doc/rustc-dev-guide/src/appendix-glossary.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-glossary.md b/src/doc/rustc-dev-guide/src/appendix-glossary.md index 23de529f2fa7d..a37f1b22fc018 100644 --- a/src/doc/rustc-dev-guide/src/appendix-glossary.md +++ b/src/doc/rustc-dev-guide/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 b70d7abcf3a5c4ed7f7685ac36125cf814e0835a Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Mon, 9 Apr 2018 21:57:57 +0530 Subject: [PATCH 0197/2516] Add: Added the instructions for debugging from rust-forge --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/debugging.md | 296 +++++++++++++++++++++++ 2 files changed, 297 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/debugging.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 3460d949d5bdb..bf770dbb8652b 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/debugging.md b/src/doc/rustc-dev-guide/src/debugging.md new file mode 100644 index 0000000000000..622728d0ddb2d --- /dev/null +++ b/src/doc/rustc-dev-guide/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 891ed67680cbf5a7539f482a44dcff6a5c37675a Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Mon, 9 Apr 2018 22:04:53 +0530 Subject: [PATCH 0198/2516] refactor: Change the name from debugging to compiler-debuggin.md --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- .../rustc-dev-guide/src/{debugging.md => compiler-debugging.md} | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename src/doc/rustc-dev-guide/src/{debugging.md => compiler-debugging.md} (100%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index bf770dbb8652b..1b96702611bc0 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md similarity index 100% rename from src/doc/rustc-dev-guide/src/debugging.md rename to src/doc/rustc-dev-guide/src/compiler-debugging.md From d175d0d3775ccc5092c29c659fef007c2bdb8d1b Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Mon, 9 Apr 2018 22:27:43 +0530 Subject: [PATCH 0199/2516] refactor: Fixed all the lines exceeding more than 80 characters --- .../rustc-dev-guide/src/compiler-debugging.md | 58 +++++++++++++------ 1 file changed, 41 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 622728d0ddb2d..41b50b04a8c65 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 9dcc68bfac4d3bd37f28e2dc9608aedb10476307 Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Tue, 10 Apr 2018 10:40:06 +0530 Subject: [PATCH 0200/2516] refactor: fixed typos, text formatting suggested in the review --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- .../rustc-dev-guide/src/compiler-debugging.md | 47 ++++++++++--------- 2 files changed, 26 insertions(+), 23 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 1b96702611bc0..1839f59cb1646 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 41b50b04a8c65..fc74caa8fe6b9 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 3e2dcd7f2cad07e3181c392ff4ef36f9e7e3e876 Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Tue, 10 Apr 2018 10:43:09 +0530 Subject: [PATCH 0201/2516] fix: changed rust code to bash formatting --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index fc74caa8fe6b9..80cbf6735625e 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 14f04d59682cb73d2574208b1dfc6073932c1468 Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Sun, 15 Apr 2018 11:49:15 +0530 Subject: [PATCH 0202/2516] add: note about copy from rust-forge --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 80cbf6735625e..4b445c924dbc7 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 636ac3849e14cad2e21398cf9aa95405d3f46728 Mon Sep 17 00:00:00 2001 From: "Ehsan M.Kermani" Date: Sun, 22 Apr 2018 16:34:32 -0700 Subject: [PATCH 0203/2516] expand compilation stages --- .../src/how-to-build-and-run.md | 23 ++++++++++++------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 535823dfd2d24..dfaf8f79bd3dd 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 c872259c5be84811045e2360487a60b843435bdf Mon Sep 17 00:00:00 2001 From: "Ehsan M.Kermani" Date: Sun, 22 Apr 2018 16:46:12 -0700 Subject: [PATCH 0204/2516] fix max line len --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index dfaf8f79bd3dd..2d979c0d1444b 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 4f6e4f8cf0779f09a29f908c4104f7995e7665f3 Mon Sep 17 00:00:00 2001 From: "Ehsan M.Kermani" Date: Sat, 28 Apr 2018 10:40:06 -0700 Subject: [PATCH 0205/2516] lint add dots --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 2d979c0d1444b..493f642a5b237 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 ebb2ec9367228426aaadbbe8a094e34ec28ad9fa Mon Sep 17 00:00:00 2001 From: Nick Fitzgerald Date: Wed, 25 Apr 2018 15:26:40 -0700 Subject: [PATCH 0206/2516] appendix-background: Link to *Static Program Analysis* A+++++ resource IMHO! --- src/doc/rustc-dev-guide/src/appendix-background.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/appendix-background.md b/src/doc/rustc-dev-guide/src/appendix-background.md index 285d74477bb4f..a0e298b05b86f 100644 --- a/src/doc/rustc-dev-guide/src/appendix-background.md +++ b/src/doc/rustc-dev-guide/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 b787599f9ed85d9c51ebdedb9d2270d9451ae473 Mon Sep 17 00:00:00 2001 From: gnzlbg Date: Tue, 8 May 2018 09:40:43 +0200 Subject: [PATCH 0207/2516] Add how to run tidy script in isolation to text This is already mentioned elsewhere, but important things are repeated twice. Closes #124 --- src/doc/rustc-dev-guide/src/conventions.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 89a986789494b..7c2a958c007e5 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 7026a5c18afe306ad22cd01d8a1a306b0adeb4db Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 8 May 2018 12:44:02 -0500 Subject: [PATCH 0208/2516] update to mdbook 0.1.7 --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index ea90e853dfabc..69b96cc732fde 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 add87abefc2d127d916126b27be19ab028ff8fd9 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 10 May 2018 08:09:56 -0400 Subject: [PATCH 0209/2516] Issue84 Add note about ./x.py build --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 493f642a5b237..66c73654824a5 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 5e4b7b40363191c368b2a816a539ea20662864d3 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 0210/2516] 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/doc/rustc-dev-guide/src/tests/adding.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 1445981ebc4e9..5d4c383f2541a 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 45409f5276e64a9bd9da0bcf50f9a3656c356760 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Wed, 9 May 2018 17:43:43 -0700 Subject: [PATCH 0211/2516] Deleted tag which was messing up the associated types page --- src/doc/rustc-dev-guide/src/traits-associated-types.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits-associated-types.md b/src/doc/rustc-dev-guide/src/traits-associated-types.md index e2dd94d5a8694..eaf497875b06b 100644 --- a/src/doc/rustc-dev-guide/src/traits-associated-types.md +++ b/src/doc/rustc-dev-guide/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 a68e44f5a8032f02258d398258dfbead43dd76b0 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Thu, 10 May 2018 11:51:34 -0700 Subject: [PATCH 0212/2516] Closing all tags --- src/doc/rustc-dev-guide/src/appendix-background.md | 10 +++++----- src/doc/rustc-dev-guide/src/conventions.md | 10 +++++----- src/doc/rustc-dev-guide/src/incremental-compilation.md | 2 +- src/doc/rustc-dev-guide/src/mir-regionck.md | 4 ++-- src/doc/rustc-dev-guide/src/mir.md | 2 +- src/doc/rustc-dev-guide/src/tests/adding.md | 8 ++++---- src/doc/rustc-dev-guide/src/traits-associated-types.md | 2 ++ src/doc/rustc-dev-guide/src/traits-bibliography.md | 4 ++-- .../rustc-dev-guide/src/traits-canonical-queries.md | 2 +- .../rustc-dev-guide/src/traits-goals-and-clauses.md | 8 ++++---- src/doc/rustc-dev-guide/src/traits-lowering-module.md | 2 +- src/doc/rustc-dev-guide/src/traits-lowering-rules.md | 6 +++--- src/doc/rustc-dev-guide/src/type-inference.md | 2 +- src/doc/rustc-dev-guide/src/variance.md | 2 +- 14 files changed, 33 insertions(+), 31 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix-background.md b/src/doc/rustc-dev-guide/src/appendix-background.md index a0e298b05b86f..0691319472e42 100644 --- a/src/doc/rustc-dev-guide/src/appendix-background.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 7c2a958c007e5..5b2b7b7f617d4 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/incremental-compilation.md b/src/doc/rustc-dev-guide/src/incremental-compilation.md index a209207fca220..0a25e16648a95 100644 --- a/src/doc/rustc-dev-guide/src/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir-regionck.md b/src/doc/rustc-dev-guide/src/mir-regionck.md index 4158b7d38111f..e67e91138c0b8 100644 --- a/src/doc/rustc-dev-guide/src/mir-regionck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir.md index da468acf42ee1..81bbf6bd686bf 100644 --- a/src/doc/rustc-dev-guide/src/mir.md +++ b/src/doc/rustc-dev-guide/src/mir.md @@ -234,7 +234,7 @@ but [you can read about those below](#promoted)). *to be written* - + ### Promoted constants diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 5d4c383f2541a..96fc0cf846d4c 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-associated-types.md b/src/doc/rustc-dev-guide/src/traits-associated-types.md index eaf497875b06b..51972c41e92a0 100644 --- a/src/doc/rustc-dev-guide/src/traits-associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-bibliography.md b/src/doc/rustc-dev-guide/src/traits-bibliography.md index 02607b525b188..b8f345d9d2e86 100644 --- a/src/doc/rustc-dev-guide/src/traits-bibliography.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-canonical-queries.md b/src/doc/rustc-dev-guide/src/traits-canonical-queries.md index 3c4bb1bfeb2b8..2737737bbbff8 100644 --- a/src/doc/rustc-dev-guide/src/traits-canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md index 5e8ee1469f584..0cbdb707743ba 100644 --- a/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-module.md b/src/doc/rustc-dev-guide/src/traits-lowering-module.md index fbf1d6425d886..08e0b95239956 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-module.md +++ b/src/doc/rustc-dev-guide/src/traits-lowering-module.md @@ -18,7 +18,7 @@ returns a vector of program clauses. [query]: ./query.html - + ## Unit tests diff --git a/src/doc/rustc-dev-guide/src/traits-lowering-rules.md b/src/doc/rustc-dev-guide/src/traits-lowering-rules.md index f7433221e7889..73660c42cf241 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-rules.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 152bbd9dadac8..e480b2b561ec3 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md index 527c2745c8255..08399b5b3af19 100644 --- a/src/doc/rustc-dev-guide/src/variance.md +++ b/src/doc/rustc-dev-guide/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 ad2eb6f6a51792d0b0965b75c2099a15b0ed7d5b Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Thu, 10 May 2018 15:22:12 -0700 Subject: [PATCH 0213/2516] Added an overview of chalk --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/chalk-overview.md | 140 ++++++++++++++++++ src/doc/rustc-dev-guide/src/traits-slg.md | 2 + 3 files changed, 143 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/chalk-overview.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 1839f59cb1646..4923d4972494f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/chalk-overview.md b/src/doc/rustc-dev-guide/src/chalk-overview.md new file mode 100644 index 0000000000000..63757f7baacf4 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-slg.md b/src/doc/rustc-dev-guide/src/traits-slg.md index cdd52ece953f1..1dc56e14c7135 100644 --- a/src/doc/rustc-dev-guide/src/traits-slg.md +++ b/src/doc/rustc-dev-guide/src/traits-slg.md @@ -1 +1,3 @@ # The SLG solver + +TODO: From 78034750d366a7c1981510b793161602704d0028 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Thu, 10 May 2018 15:43:18 -0700 Subject: [PATCH 0214/2516] Lines must be <= 80 characters UNLESS there is a link --- src/doc/rustc-dev-guide/src/chalk-overview.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/chalk-overview.md b/src/doc/rustc-dev-guide/src/chalk-overview.md index 63757f7baacf4..8c5bc1594fce2 100644 --- a/src/doc/rustc-dev-guide/src/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 cf689b2db429c6286b47b009cc9df26a9b56cba6 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Thu, 10 May 2018 15:48:24 -0700 Subject: [PATCH 0215/2516] Ignoring code examples that aren't actually compile-able --- src/doc/rustc-dev-guide/src/chalk-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/chalk-overview.md b/src/doc/rustc-dev-guide/src/chalk-overview.md index 8c5bc1594fce2..49f6851491756 100644 --- a/src/doc/rustc-dev-guide/src/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 6d9f93579156f76512595acbd6c1343c1682c17e Mon Sep 17 00:00:00 2001 From: C Jones Date: Fri, 11 May 2018 18:16:15 -0400 Subject: [PATCH 0216/2516] 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/doc/rustc-dev-guide/src/compiletest.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 363c12d3b328f..cdcede33a4328 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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 a5254db9b72940af4657bed2b68cf7ece9044225 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Fri, 11 May 2018 17:14:26 -0700 Subject: [PATCH 0217/2516] Updating links to match latest code --- src/doc/rustc-dev-guide/src/chalk-overview.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/chalk-overview.md b/src/doc/rustc-dev-guide/src/chalk-overview.md index 49f6851491756..7cea6acef7b3e 100644 --- a/src/doc/rustc-dev-guide/src/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 af56bb3f5e2edce5f41c7d9a77bf4a06f0019e2f Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 8 May 2018 12:40:43 -0500 Subject: [PATCH 0218/2516] reword HIR intro. Fix #116 --- src/doc/rustc-dev-guide/src/hir.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 3d2fbede3c4fe..51296e55e5218 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 9e905bc935a7609159706a4bdb16f2f38aa72c86 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 12 May 2018 15:01:58 -0500 Subject: [PATCH 0219/2516] remove have completed --- src/doc/rustc-dev-guide/src/hir.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 51296e55e5218..06ee5e1059611 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 3788625a9769388298d865e7bf4f0a8bcc4b1ea6 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Mon, 14 May 2018 10:52:21 -0700 Subject: [PATCH 0220/2516] Changes from review --- src/doc/rustc-dev-guide/src/chalk-overview.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/chalk-overview.md b/src/doc/rustc-dev-guide/src/chalk-overview.md index 7cea6acef7b3e..cd2c98b88ea6c 100644 --- a/src/doc/rustc-dev-guide/src/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 97c8ed36232a3cc2ab696d86022143e0ef7f2d84 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Mon, 14 May 2018 11:18:14 -0700 Subject: [PATCH 0221/2516] More review changes --- src/doc/rustc-dev-guide/src/chalk-overview.md | 21 ++++++++++--------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/chalk-overview.md b/src/doc/rustc-dev-guide/src/chalk-overview.md index cd2c98b88ea6c..926c7f5ace5e8 100644 --- a/src/doc/rustc-dev-guide/src/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 7741e2f4caab612a4cb8d49d3d20708719ca4b1d Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Mon, 14 May 2018 11:21:20 -0700 Subject: [PATCH 0222/2516] Even more review changes --- src/doc/rustc-dev-guide/src/chalk-overview.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/chalk-overview.md b/src/doc/rustc-dev-guide/src/chalk-overview.md index 926c7f5ace5e8..02e0942930155 100644 --- a/src/doc/rustc-dev-guide/src/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 131ae09207f37a46d1bb3f1de6565bd773b40e36 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Mon, 14 May 2018 11:26:15 -0700 Subject: [PATCH 0223/2516] Missed a few things because of GitHub's UI --- src/doc/rustc-dev-guide/src/chalk-overview.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/chalk-overview.md b/src/doc/rustc-dev-guide/src/chalk-overview.md index 02e0942930155..76c119a5ed342 100644 --- a/src/doc/rustc-dev-guide/src/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 bcb81eb491620d9d1daedf9746e70b1a94159c81 Mon Sep 17 00:00:00 2001 From: Takanori Ishibashi Date: Tue, 15 May 2018 21:59:30 +0900 Subject: [PATCH 0224/2516] invokations -> invocations --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index ba807faf28576..a90ad517ba432 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 82c1fa408988090fee48e05b56e1c1e6bd2e8484 Mon Sep 17 00:00:00 2001 From: Alex Kitchens Date: Thu, 17 May 2018 12:53:11 -0500 Subject: [PATCH 0225/2516] 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/doc/rustc-dev-guide/src/high-level-overview.md | 5 +++-- src/doc/rustc-dev-guide/src/hir.md | 10 +++++----- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 9f3b63a549e7b..be396054bda76 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 06ee5e1059611..44c4968b13bff 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 6c6630d79e96d0e9b0362d5a163c5610a58ced56 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Mon, 21 May 2018 13:16:16 +0200 Subject: [PATCH 0226/2516] 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/doc/rustc-dev-guide/src/type-inference.md | 20 +++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index e480b2b561ec3..4795e23c1264c 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 577f8ddba62b10f4434a0291234ca86fd1d13051 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Mon, 21 May 2018 19:44:07 +0200 Subject: [PATCH 0227/2516] The type is inferenced, not things itself. --- src/doc/rustc-dev-guide/src/type-inference.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 4795e23c1264c..9ae88decd1a51 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 d6df2a2f92b17a367d771ff3f89592250663023f Mon Sep 17 00:00:00 2001 From: Alex Kitchens Date: Tue, 22 May 2018 16:30:05 -0500 Subject: [PATCH 0228/2516] 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/doc/rustc-dev-guide/src/query.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 2c518ee55ee4c..d48b6e7e3da76 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 03a905fa14b26c6590d7d86a8ff97660c064badd Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Wed, 23 May 2018 11:55:16 +0200 Subject: [PATCH 0229/2516] Fixes #141 --- src/doc/rustc-dev-guide/src/tests/adding.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 96fc0cf846d4c..16e4982b0870f 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 dfd204e5e74543f4015418c78957f1d96dd26c5e Mon Sep 17 00:00:00 2001 From: Takanori Ishibashi Date: Sat, 26 May 2018 16:36:27 +0900 Subject: [PATCH 0230/2516] Fix typo --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index a90ad517ba432..df0dc7b1dc357 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 bce2d112addc7a7c67369599a91b5eb8279ffd3b Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Fri, 11 May 2018 21:06:21 -0500 Subject: [PATCH 0231/2516] Clarify language in Trait Resolution --- src/doc/rustc-dev-guide/src/trait-resolution.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/trait-resolution.md index 5bf8f8716fc7c..b9fa81bd6c048 100644 --- a/src/doc/rustc-dev-guide/src/trait-resolution.md +++ b/src/doc/rustc-dev-guide/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 ae59da11468b6806fcad78e1f0b69acd71dc6151 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Fri, 25 May 2018 23:03:09 -0400 Subject: [PATCH 0232/2516] 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/doc/rustc-dev-guide/src/traits-goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md index 0cbdb707743ba..882f86b8edf7c 100644 --- a/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-rules.md b/src/doc/rustc-dev-guide/src/traits-lowering-rules.md index 73660c42cf241..80884cbdd5614 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-rules.md +++ b/src/doc/rustc-dev-guide/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 6464cc404e15f5d5407a5ebf706fc70f65c979ed Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 13:40:37 -0500 Subject: [PATCH 0233/2516] Add info about emitting lints and errors --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/appendix-code-index.md | 3 + src/doc/rustc-dev-guide/src/diag.md | 176 ++++++++++++++++++ 3 files changed, 180 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/diag.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 4923d4972494f..2db3e62c34f70 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix-code-index.md b/src/doc/rustc-dev-guide/src/appendix-code-index.md index 62edd0f5b1cdc..915d00828de15 100644 --- a/src/doc/rustc-dev-guide/src/appendix-code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md new file mode 100644 index 0000000000000..25f45e0029287 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 96e5a9d04000c7440b90d9a25a0b697c6ac9ea93 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 13:46:33 -0500 Subject: [PATCH 0234/2516] 80 chars --- src/doc/rustc-dev-guide/src/diag.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 25f45e0029287..6679e424941e4 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 385457dc99728cc382276467ccf5cf127d5572af Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 14:55:55 -0500 Subject: [PATCH 0235/2516] Address reviewers' comments --- src/doc/rustc-dev-guide/src/diag.md | 86 ++++++++++++++++++++++++++--- 1 file changed, 77 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 6679e424941e4..a2ec3bb7e35bb 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 adacc97a5b7f1ae99b4bab532115069eff6a7f20 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 15:00:27 -0500 Subject: [PATCH 0236/2516] add more on applicabilities --- src/doc/rustc-dev-guide/src/diag.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index a2ec3bb7e35bb..8b067fde78fc3 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 f65df573d69086a492ac4c685f49c5d8571eb5e2 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 15:01:04 -0500 Subject: [PATCH 0237/2516] line length --- src/doc/rustc-dev-guide/src/diag.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 8b067fde78fc3..af619ed83a774 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 13c876b1775b0cc26cc898ccbd6523329ac6fa26 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 15:05:57 -0500 Subject: [PATCH 0238/2516] fix typo --- src/doc/rustc-dev-guide/src/diag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index af619ed83a774..6043a79b7bedd 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 9337709aa027813c08654f4392a68aafe77122f9 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Mon, 28 May 2018 13:08:15 +0200 Subject: [PATCH 0239/2516] Mention "run-rustfix" --- src/doc/rustc-dev-guide/src/tests/adding.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 16e4982b0870f..e8075e53953b6 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 19e3d42bbb23820090c31c0a1dc53484f69a6476 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Tue, 29 May 2018 15:37:24 +0200 Subject: [PATCH 0240/2516] Explain .fixed files --- src/doc/rustc-dev-guide/src/tests/adding.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index e8075e53953b6..daaaace7e38dd 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 f906594e20795721ee272857815608ab07982119 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Tue, 29 May 2018 16:31:32 +0200 Subject: [PATCH 0241/2516] Satisfy travis --- src/doc/rustc-dev-guide/src/tests/adding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index daaaace7e38dd..3788e7c41c567 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 b1fb4beeffe54a4f51b359144b2f7a5b808d75b3 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 30 May 2018 22:57:34 -0500 Subject: [PATCH 0242/2516] 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/doc/rustc-dev-guide/src/traits-associated-types.md b/src/doc/rustc-dev-guide/src/traits-associated-types.md index 51972c41e92a0..ec20985ffe308 100644 --- a/src/doc/rustc-dev-guide/src/traits-associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits-lowering-rules.md b/src/doc/rustc-dev-guide/src/traits-lowering-rules.md index 80884cbdd5614..06dc67401196d 100644 --- a/src/doc/rustc-dev-guide/src/traits-lowering-rules.md +++ b/src/doc/rustc-dev-guide/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 47bb51958ae6645919db54e80c9b455ad51448a4 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 2 Jun 2018 16:06:00 -0500 Subject: [PATCH 0243/2516] clarify run-rustfix compiletest header --- src/doc/rustc-dev-guide/src/tests/adding.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 3788e7c41c567..28f4c1140aba1 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 286003648bea380adb9cde15983bfc8bf3696731 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 11:46:47 -0500 Subject: [PATCH 0244/2516] 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/doc/rustc-dev-guide/src/{appendix-background.md => appendix/background.md} (100%) rename src/doc/rustc-dev-guide/src/{appendix-code-index.md => appendix/code-index.md} (100%) rename src/doc/rustc-dev-guide/src/{appendix-glossary.md => appendix/glossary.md} (100%) rename src/doc/rustc-dev-guide/src/{appendix-stupid-stats.md => appendix/stupid-stats.md} (100%) diff --git a/src/doc/rustc-dev-guide/src/appendix-background.md b/src/doc/rustc-dev-guide/src/appendix/background.md similarity index 100% rename from src/doc/rustc-dev-guide/src/appendix-background.md rename to src/doc/rustc-dev-guide/src/appendix/background.md diff --git a/src/doc/rustc-dev-guide/src/appendix-code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md similarity index 100% rename from src/doc/rustc-dev-guide/src/appendix-code-index.md rename to src/doc/rustc-dev-guide/src/appendix/code-index.md diff --git a/src/doc/rustc-dev-guide/src/appendix-glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md similarity index 100% rename from src/doc/rustc-dev-guide/src/appendix-glossary.md rename to src/doc/rustc-dev-guide/src/appendix/glossary.md diff --git a/src/doc/rustc-dev-guide/src/appendix-stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md similarity index 100% rename from src/doc/rustc-dev-guide/src/appendix-stupid-stats.md rename to src/doc/rustc-dev-guide/src/appendix/stupid-stats.md From 466423e237c019fdb533ad894062f5e09e1f18b2 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 11:49:24 -0500 Subject: [PATCH 0245/2516] move mir --- src/doc/rustc-dev-guide/src/{mir-borrowck.md => mir/borrowck.md} | 0 .../src/{mir-construction.md => mir/construction.md} | 0 src/doc/rustc-dev-guide/src/{mir.md => mir/index.md} | 0 .../src/{mir-optimizations.md => mir/optimizations.md} | 0 src/doc/rustc-dev-guide/src/{mir-passes.md => mir/passes.md} | 0 src/doc/rustc-dev-guide/src/{mir-regionck.md => mir/regionck.md} | 0 src/doc/rustc-dev-guide/src/{mir-visitor.md => mir/visitor.md} | 0 7 files changed, 0 insertions(+), 0 deletions(-) rename src/doc/rustc-dev-guide/src/{mir-borrowck.md => mir/borrowck.md} (100%) rename src/doc/rustc-dev-guide/src/{mir-construction.md => mir/construction.md} (100%) rename src/doc/rustc-dev-guide/src/{mir.md => mir/index.md} (100%) rename src/doc/rustc-dev-guide/src/{mir-optimizations.md => mir/optimizations.md} (100%) rename src/doc/rustc-dev-guide/src/{mir-passes.md => mir/passes.md} (100%) rename src/doc/rustc-dev-guide/src/{mir-regionck.md => mir/regionck.md} (100%) rename src/doc/rustc-dev-guide/src/{mir-visitor.md => mir/visitor.md} (100%) diff --git a/src/doc/rustc-dev-guide/src/mir-borrowck.md b/src/doc/rustc-dev-guide/src/mir/borrowck.md similarity index 100% rename from src/doc/rustc-dev-guide/src/mir-borrowck.md rename to src/doc/rustc-dev-guide/src/mir/borrowck.md diff --git a/src/doc/rustc-dev-guide/src/mir-construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md similarity index 100% rename from src/doc/rustc-dev-guide/src/mir-construction.md rename to src/doc/rustc-dev-guide/src/mir/construction.md diff --git a/src/doc/rustc-dev-guide/src/mir.md b/src/doc/rustc-dev-guide/src/mir/index.md similarity index 100% rename from src/doc/rustc-dev-guide/src/mir.md rename to src/doc/rustc-dev-guide/src/mir/index.md diff --git a/src/doc/rustc-dev-guide/src/mir-optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md similarity index 100% rename from src/doc/rustc-dev-guide/src/mir-optimizations.md rename to src/doc/rustc-dev-guide/src/mir/optimizations.md diff --git a/src/doc/rustc-dev-guide/src/mir-passes.md b/src/doc/rustc-dev-guide/src/mir/passes.md similarity index 100% rename from src/doc/rustc-dev-guide/src/mir-passes.md rename to src/doc/rustc-dev-guide/src/mir/passes.md diff --git a/src/doc/rustc-dev-guide/src/mir-regionck.md b/src/doc/rustc-dev-guide/src/mir/regionck.md similarity index 100% rename from src/doc/rustc-dev-guide/src/mir-regionck.md rename to src/doc/rustc-dev-guide/src/mir/regionck.md diff --git a/src/doc/rustc-dev-guide/src/mir-visitor.md b/src/doc/rustc-dev-guide/src/mir/visitor.md similarity index 100% rename from src/doc/rustc-dev-guide/src/mir-visitor.md rename to src/doc/rustc-dev-guide/src/mir/visitor.md From 0ea6270060fbe185166d777f9756673a6834bb0e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 11:54:23 -0500 Subject: [PATCH 0246/2516] mv traits --- .../{traits-associated-types.md => traits/associated-types.md} | 0 .../src/{traits-bibliography.md => traits/bibliography.md} | 0 .../rustc-dev-guide/src/{trait-caching.md => traits/caching.md} | 0 .../{traits-canonical-queries.md => traits/canonical-queries.md} | 0 .../{traits-canonicalization.md => traits/canonicalization.md} | 0 .../{traits-goals-and-clauses.md => traits/goals-and-clauses.md} | 0 src/doc/rustc-dev-guide/src/{trait-hrtb.md => traits/hrtb.md} | 0 .../src/{traits-implied-bounds.md => traits/implied-bounds.md} | 0 src/doc/rustc-dev-guide/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 .../{traits-lowering-to-logic.md => traits/lowering-to-logic.md} | 0 .../rustc-dev-guide/src/{traits-regions.md => traits/regions.md} | 0 .../src/{trait-resolution.md => traits/resolution.md} | 0 src/doc/rustc-dev-guide/src/{traits-slg.md => traits/slg.md} | 0 src/doc/rustc-dev-guide/src/{traits-wf.md => traits/wf.md} | 0 16 files changed, 0 insertions(+), 0 deletions(-) rename src/doc/rustc-dev-guide/src/{traits-associated-types.md => traits/associated-types.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-bibliography.md => traits/bibliography.md} (100%) rename src/doc/rustc-dev-guide/src/{trait-caching.md => traits/caching.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-canonical-queries.md => traits/canonical-queries.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-canonicalization.md => traits/canonicalization.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-goals-and-clauses.md => traits/goals-and-clauses.md} (100%) rename src/doc/rustc-dev-guide/src/{trait-hrtb.md => traits/hrtb.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-implied-bounds.md => traits/implied-bounds.md} (100%) rename src/doc/rustc-dev-guide/src/{traits.md => traits/index.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-lowering-module.md => traits/lowering-module.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-lowering-rules.md => traits/lowering-rules.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-lowering-to-logic.md => traits/lowering-to-logic.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-regions.md => traits/regions.md} (100%) rename src/doc/rustc-dev-guide/src/{trait-resolution.md => traits/resolution.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-slg.md => traits/slg.md} (100%) rename src/doc/rustc-dev-guide/src/{traits-wf.md => traits/wf.md} (100%) diff --git a/src/doc/rustc-dev-guide/src/traits-associated-types.md b/src/doc/rustc-dev-guide/src/traits/associated-types.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-associated-types.md rename to src/doc/rustc-dev-guide/src/traits/associated-types.md diff --git a/src/doc/rustc-dev-guide/src/traits-bibliography.md b/src/doc/rustc-dev-guide/src/traits/bibliography.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-bibliography.md rename to src/doc/rustc-dev-guide/src/traits/bibliography.md diff --git a/src/doc/rustc-dev-guide/src/trait-caching.md b/src/doc/rustc-dev-guide/src/traits/caching.md similarity index 100% rename from src/doc/rustc-dev-guide/src/trait-caching.md rename to src/doc/rustc-dev-guide/src/traits/caching.md diff --git a/src/doc/rustc-dev-guide/src/traits-canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-canonical-queries.md rename to src/doc/rustc-dev-guide/src/traits/canonical-queries.md diff --git a/src/doc/rustc-dev-guide/src/traits-canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-canonicalization.md rename to src/doc/rustc-dev-guide/src/traits/canonicalization.md diff --git a/src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-goals-and-clauses.md rename to src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md diff --git a/src/doc/rustc-dev-guide/src/trait-hrtb.md b/src/doc/rustc-dev-guide/src/traits/hrtb.md similarity index 100% rename from src/doc/rustc-dev-guide/src/trait-hrtb.md rename to src/doc/rustc-dev-guide/src/traits/hrtb.md diff --git a/src/doc/rustc-dev-guide/src/traits-implied-bounds.md b/src/doc/rustc-dev-guide/src/traits/implied-bounds.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-implied-bounds.md rename to src/doc/rustc-dev-guide/src/traits/implied-bounds.md diff --git a/src/doc/rustc-dev-guide/src/traits.md b/src/doc/rustc-dev-guide/src/traits/index.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits.md rename to src/doc/rustc-dev-guide/src/traits/index.md diff --git a/src/doc/rustc-dev-guide/src/traits-lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-lowering-module.md rename to src/doc/rustc-dev-guide/src/traits/lowering-module.md diff --git a/src/doc/rustc-dev-guide/src/traits-lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-lowering-rules.md rename to src/doc/rustc-dev-guide/src/traits/lowering-rules.md diff --git a/src/doc/rustc-dev-guide/src/traits-lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-lowering-to-logic.md rename to src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md diff --git a/src/doc/rustc-dev-guide/src/traits-regions.md b/src/doc/rustc-dev-guide/src/traits/regions.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-regions.md rename to src/doc/rustc-dev-guide/src/traits/regions.md diff --git a/src/doc/rustc-dev-guide/src/trait-resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md similarity index 100% rename from src/doc/rustc-dev-guide/src/trait-resolution.md rename to src/doc/rustc-dev-guide/src/traits/resolution.md diff --git a/src/doc/rustc-dev-guide/src/traits-slg.md b/src/doc/rustc-dev-guide/src/traits/slg.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-slg.md rename to src/doc/rustc-dev-guide/src/traits/slg.md diff --git a/src/doc/rustc-dev-guide/src/traits-wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md similarity index 100% rename from src/doc/rustc-dev-guide/src/traits-wf.md rename to src/doc/rustc-dev-guide/src/traits/wf.md From 1ab97d4a813577997e7e0a9315b8e88dd9635516 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 12:13:46 -0500 Subject: [PATCH 0247/2516] first round of link fixes --- src/doc/rustc-dev-guide/src/SUMMARY.md | 52 +++++++++---------- src/doc/rustc-dev-guide/src/rustc-driver.md | 22 ++++---- src/doc/rustc-dev-guide/src/traits/caching.md | 4 +- .../src/traits/canonical-queries.md | 6 +-- .../src/traits/canonicalization.md | 6 +-- .../src/traits/goals-and-clauses.md | 13 ++--- src/doc/rustc-dev-guide/src/traits/index.md | 12 ++--- .../src/traits/lowering-module.md | 2 +- .../src/traits/lowering-rules.md | 10 ++-- .../src/traits/lowering-to-logic.md | 4 +- .../rustc-dev-guide/src/traits/resolution.md | 2 +- src/doc/rustc-dev-guide/src/type-inference.md | 2 +- 12 files changed, 68 insertions(+), 67 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 2db3e62c34f70..a2b7d3e13027c 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index af3c3c099dfed..1550b14e9bb16 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/caching.md b/src/doc/rustc-dev-guide/src/traits/caching.md index 4b7d7e096365b..228ff0917ec75 100644 --- a/src/doc/rustc-dev-guide/src/traits/caching.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md index 2737737bbbff8..56637dace30e5 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md index fa39151d73b59..37a59026b423f 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index 882f86b8edf7c..5844e8d45f4d1 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/index.md b/src/doc/rustc-dev-guide/src/traits/index.md index 175e6418b0866..6aad2474d02b8 100644 --- a/src/doc/rustc-dev-guide/src/traits/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md index 08e0b95239956..205e9a171aa44 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-module.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md index 06dc67401196d..f635ee85769c5 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md index 54b3473d40d90..2de28ce4e3f9f 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md index b9fa81bd6c048..e33e0c8ec70e3 100644 --- a/src/doc/rustc-dev-guide/src/traits/resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 9ae88decd1a51..a3d012b5dff7b 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 05e67188737682ae191b5df35f12268f918d0fac Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 12:30:10 -0500 Subject: [PATCH 0248/2516] fix remaining links --- src/doc/rustc-dev-guide/src/SUMMARY.md | 6 ++-- .../rustc-dev-guide/src/appendix/glossary.md | 30 +++++++++---------- src/doc/rustc-dev-guide/src/mir/borrowck.md | 12 ++++---- src/doc/rustc-dev-guide/src/mir/index.md | 4 +-- src/doc/rustc-dev-guide/src/mir/passes.md | 2 +- src/doc/rustc-dev-guide/src/mir/regionck.md | 8 ++--- .../src/traits/canonicalization.md | 2 +- .../src/{ => traits}/chalk-overview.md | 10 +++---- src/doc/rustc-dev-guide/src/traits/index.md | 2 +- .../specialization.md} | 0 src/doc/rustc-dev-guide/src/type-checking.md | 2 +- src/doc/rustc-dev-guide/src/variance.md | 2 +- 12 files changed, 40 insertions(+), 40 deletions(-) rename src/doc/rustc-dev-guide/src/{ => traits}/chalk-overview.md (95%) rename src/doc/rustc-dev-guide/src/{trait-specialization.md => traits/specialization.md} (100%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index a2b7d3e13027c..8efe304b73f74 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index a37f1b22fc018..ad2604e63cfd3 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/borrowck.md b/src/doc/rustc-dev-guide/src/mir/borrowck.md index 51a6c6cbf2692..cd83843f89d35 100644 --- a/src/doc/rustc-dev-guide/src/mir/borrowck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index 81bbf6bd686bf..838048b81a4e5 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/passes.md b/src/doc/rustc-dev-guide/src/mir/passes.md index 64e72f06e4559..a5b5df10a99ed 100644 --- a/src/doc/rustc-dev-guide/src/mir/passes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/regionck.md b/src/doc/rustc-dev-guide/src/mir/regionck.md index e67e91138c0b8..90f6fa2749f14 100644 --- a/src/doc/rustc-dev-guide/src/mir/regionck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md index 37a59026b423f..f87de5f814f1c 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md similarity index 95% rename from src/doc/rustc-dev-guide/src/chalk-overview.md rename to src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 76c119a5ed342..e737edcd912d7 100644 --- a/src/doc/rustc-dev-guide/src/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/index.md b/src/doc/rustc-dev-guide/src/traits/index.md index 6aad2474d02b8..2dabd0b69677f 100644 --- a/src/doc/rustc-dev-guide/src/traits/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trait-specialization.md b/src/doc/rustc-dev-guide/src/traits/specialization.md similarity index 100% rename from src/doc/rustc-dev-guide/src/trait-specialization.md rename to src/doc/rustc-dev-guide/src/traits/specialization.md diff --git a/src/doc/rustc-dev-guide/src/type-checking.md b/src/doc/rustc-dev-guide/src/type-checking.md index cb6d346e4c2c5..9a161abd21115 100644 --- a/src/doc/rustc-dev-guide/src/type-checking.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md index 08399b5b3af19..05a286c075c1f 100644 --- a/src/doc/rustc-dev-guide/src/variance.md +++ b/src/doc/rustc-dev-guide/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 57183e55b285f8ee323d3264ec1746ae22bba060 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 12:38:46 -0500 Subject: [PATCH 0249/2516] allow long relative links --- src/doc/rustc-dev-guide/ci/check_line_lengths.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh b/src/doc/rustc-dev-guide/ci/check_line_lengths.sh index dc48091c87334..91f199b7e3654 100755 --- a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh +++ b/src/doc/rustc-dev-guide/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 2f071e15163abc1cfa761970dae9e8b0266ff86a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 19:42:16 -0500 Subject: [PATCH 0250/2516] add a bunch of type-related terms to glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index ad2604e63cfd3..a6f4e7b1c2e5b 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 57b11c564da612d4ca6e0d0445316c711f8adf77 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 20:26:40 -0500 Subject: [PATCH 0251/2516] A few more data structures to the code index --- .../rustc-dev-guide/src/appendix/code-index.md | 18 ++++++++++++++++-- src/doc/rustc-dev-guide/src/hir.md | 2 ++ src/doc/rustc-dev-guide/src/the-parser.md | 10 +++++----- 3 files changed, 23 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 915d00828de15..62fa6bd934444 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 44c4968b13bff..2a11531ee6b4d 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index 623a38e672a67..dd451d24fcefa 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 f4936f90ca612e8226a118bc19431a66146bea45 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 3 Jun 2018 22:09:21 -0500 Subject: [PATCH 0252/2516] add a bit about crater --- src/doc/rustc-dev-guide/src/tests/intro.md | 33 +++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index e8cf34aff7765..7c3832ed9dff3 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 9dba2ae6608c3a687cb16598fcf87b919f7e4c24 Mon Sep 17 00:00:00 2001 From: Mark Date: Sun, 3 Jun 2018 22:40:29 -0500 Subject: [PATCH 0253/2516] add more on crater + perf runs --- src/doc/rustc-dev-guide/src/tests/intro.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 7c3832ed9dff3..034b7aac1c5da 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 ef153231776b10b5212ada9d30498ced9518560f Mon Sep 17 00:00:00 2001 From: Mark Date: Sun, 3 Jun 2018 22:46:11 -0500 Subject: [PATCH 0254/2516] Address review feedback --- src/doc/rustc-dev-guide/src/tests/intro.md | 25 ++++++++++++++-------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 034b7aac1c5da..f4164de5ee616 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 ff2305ff199ae433c836cf0700a1b871fc500071 Mon Sep 17 00:00:00 2001 From: Mark Date: Sun, 3 Jun 2018 22:48:03 -0500 Subject: [PATCH 0255/2516] long line --- src/doc/rustc-dev-guide/src/tests/intro.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index f4164de5ee616..79aa0fd6a6c12 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 a0dc2497d0c13266a44043af3f86851a9fa3bdfe Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 19:23:19 -0500 Subject: [PATCH 0256/2516] tests dont need to pass --- src/doc/rustc-dev-guide/src/tests/intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 79aa0fd6a6c12..bd8a60a883403 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 38d6e58799490bd1f9f23901e3a51da5d70745b3 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 19:46:05 -0500 Subject: [PATCH 0257/2516] fix typo --- src/doc/rustc-dev-guide/src/tests/intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index bd8a60a883403..bc84c9721f500 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 047464aa425f2b9cef43ce24138c9ef1d11fdddc Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 20:40:23 -0500 Subject: [PATCH 0258/2516] 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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 66c73654824a5..54e60ddcb4d00 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 e0a03290270f698d5f0d172f140f688ef965118d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 23:18:46 -0500 Subject: [PATCH 0259/2516] fix build --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 54e60ddcb4d00..557fc9148ed8b 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 51c8f5153862b552fe4d273065dc25294e81e98e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 8 Jun 2018 20:32:04 -0500 Subject: [PATCH 0260/2516] mention bless --- src/doc/rustc-dev-guide/src/tests/adding.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 28f4c1140aba1..fac13fcacfeea 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 e10360364658f51f09dd2618506cb5a55af583bd Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sat, 9 Jun 2018 00:32:06 +0100 Subject: [PATCH 0261/2516] removed whitespace --- src/doc/rustc-dev-guide/book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index f3a192c678444..ecbe513b7cbe0 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 6cab9030bf2692f7f63d500f3a6e023d63a0236f Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 8 Jun 2018 20:38:38 -0500 Subject: [PATCH 0262/2516] update trait ref --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 62fa6bd934444..ef7853fc6f8d6 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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 08dfae74c71706bbf1ff7e08e7e7e81f3750710b Mon Sep 17 00:00:00 2001 From: scalexm Date: Thu, 7 Jun 2018 12:13:40 +0200 Subject: [PATCH 0263/2516] Add chalk rules for type defs --- .../src/traits/lowering-rules.md | 76 ++++++++++++++++++- 1 file changed, 75 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md index f635ee85769c5..e3febd9f27a85 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md +++ b/src/doc/rustc-dev-guide/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 eea3079a571ae161d40ba283099c8c2e86de7f36 Mon Sep 17 00:00:00 2001 From: scalexm Date: Tue, 12 Jun 2018 19:27:04 +0200 Subject: [PATCH 0264/2516] Capitalize a word --- src/doc/rustc-dev-guide/src/traits/lowering-rules.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md index e3febd9f27a85..d8b73989091b9 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md +++ b/src/doc/rustc-dev-guide/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 e55064475dac7f938a29a8e717a3224fe6c80288 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 2 Jun 2018 21:58:53 -0700 Subject: [PATCH 0265/2516] include `./` in example x.py commands for smoother copy-paste experience The current directory is typically not on the user's $PATH. --- src/doc/rustc-dev-guide/src/rustdoc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 36195c3a5625b..5bdfbeb6a8792 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 a40bb3a5fbfeb165224919084e47968aa511b76c Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sun, 24 Jun 2018 19:08:02 -0700 Subject: [PATCH 0266/2516] don't mention new rustdoc Steve says it's not ready (https://github.com/rust-lang-nursery/rustc-guide/pull/150#issuecomment-395783504). --- src/doc/rustc-dev-guide/src/rustdoc.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 5bdfbeb6a8792..76a8b28ce7da3 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 2b2972332fad3c2383e428f8a6393a3911710089 Mon Sep 17 00:00:00 2001 From: Eduard-Mihai Burtescu Date: Thu, 14 Jun 2018 20:35:35 +0300 Subject: [PATCH 0267/2516] rustc: rename ty::maps to ty::query. --- .../rustc-dev-guide/src/high-level-overview.md | 2 +- src/doc/rustc-dev-guide/src/query.md | 16 ++++++++-------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index be396054bda76..dce6b4c4130a3 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index d48b6e7e3da76..62a6271358e05 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 e7d4e79e3b357fda3db6cae4a6e2f7c1b07ee91f Mon Sep 17 00:00:00 2001 From: Eduard-Mihai Burtescu Date: Mon, 25 Jun 2018 07:07:19 +0300 Subject: [PATCH 0268/2516] Update high-level-overview.md --- src/doc/rustc-dev-guide/src/high-level-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index dce6b4c4130a3..8e49afaa94f63 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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 5966f8e7846398662ffc9b021ffbfb07f08bd6a7 Mon Sep 17 00:00:00 2001 From: Eduard-Mihai Burtescu Date: Mon, 25 Jun 2018 07:09:22 +0300 Subject: [PATCH 0269/2516] Update query.md --- src/doc/rustc-dev-guide/src/query.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 62a6271358e05..7ed299b74e8ad 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 3c51d758e2ecfa28b417f594ea29552fa946f2c4 Mon Sep 17 00:00:00 2001 From: Alex Kitchens Date: Sun, 24 Jun 2018 21:56:01 -0500 Subject: [PATCH 0270/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/appendix/glossary.md | 4 ++-- src/doc/rustc-dev-guide/src/{trans.md => codegen.md} | 0 src/doc/rustc-dev-guide/src/high-level-overview.md | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) rename src/doc/rustc-dev-guide/src/{trans.md => codegen.md} (100%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 8efe304b73f74..f60fee488ce8b 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index a6f4e7b1c2e5b..c2947090a4c1e 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/trans.md b/src/doc/rustc-dev-guide/src/codegen.md similarity index 100% rename from src/doc/rustc-dev-guide/src/trans.md rename to src/doc/rustc-dev-guide/src/codegen.md diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 8e49afaa94f63..60b9e80ea23ee 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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 abfac5a722b26bf0d45fb014030bc6bdb0089f5c Mon Sep 17 00:00:00 2001 From: Alex Kitchens Date: Tue, 26 Jun 2018 11:28:30 -0500 Subject: [PATCH 0271/2516] Keep glossary definition of codegen --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index c2947090a4c1e..bfc2c0d22ee07 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 c622464ef201125d32f5427bf1c04b33b8c89ff2 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 08:34:31 -0700 Subject: [PATCH 0272/2516] 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/doc/rustc-dev-guide/src/diag.md | 33 +++++++++++++++++------------ 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 6043a79b7bedd..389ba2bbcb33b 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 0b7ea143465aa1b5f243a5e51ffc726dd212fe77 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 08:37:15 -0700 Subject: [PATCH 0273/2516] `span_to_snippet` return value is a `Result`, not an `Option` --- src/doc/rustc-dev-guide/src/diag.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 389ba2bbcb33b..5984e8621d2bd 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 fa644901e94fb740741d495f04220a5ebf77694e Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 08:50:28 -0700 Subject: [PATCH 0274/2516] =?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/doc/rustc-dev-guide/src/diag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 5984e8621d2bd..0bef3e2741269 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 3a851001e05ddc15b3447cf160b74bb4b81cddae Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 08:55:04 -0700 Subject: [PATCH 0275/2516] cautionary parenthetical about failing to emit a `DiagnosticBuilder` --- src/doc/rustc-dev-guide/src/diag.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 0bef3e2741269..26fc200af6966 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 6fd934ddeaf45ca085eedda5c56191e17858df0b Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 09:03:00 -0700 Subject: [PATCH 0276/2516] mention lint-level command line flags as well as attributes --- src/doc/rustc-dev-guide/src/diag.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 26fc200af6966..e4c257fd8a4ef 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 d771413d9d91ed3e05619cd128d13cbb1a90ee47 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 16:55:13 -0700 Subject: [PATCH 0277/2516] 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/doc/rustc-dev-guide/src/diag.md | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index e4c257fd8a4ef..a0e755718b131 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 19d6a4ace49db2991dff7c0911490bf1753a6a99 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 17:03:08 -0700 Subject: [PATCH 0278/2516] =?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/doc/rustc-dev-guide/src/diag.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index a0e755718b131..67bd4829c4de6 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 7efa4132cba3eac54004e95a46657fcb1b0d0a16 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 4 Jul 2018 17:17:20 -0500 Subject: [PATCH 0279/2516] add a link to the rustc docs --- src/doc/rustc-dev-guide/README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 07d1749e8c759..5dc64ed4de1fe 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 86d807ba75462ce468b6a68fc485f53b6676357e Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Fri, 1 Jun 2018 17:34:45 +0200 Subject: [PATCH 0280/2516] Add some explanation of lowering ids --- .../src/high-level-overview.md | 3 +- src/doc/rustc-dev-guide/src/lowering.md | 35 +++++++++++++++++++ 2 files changed, 37 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/src/lowering.md diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 60b9e80ea23ee..733c523c90e6f 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/lowering.md b/src/doc/rustc-dev-guide/src/lowering.md new file mode 100644 index 0000000000000..335513342c429 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 cbce2e4a3cafb9732087269a4d18b82efd21768a Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Thu, 5 Jul 2018 09:30:05 +0200 Subject: [PATCH 0281/2516] Address review --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/hir.md | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index f60fee488ce8b..a41f78a1a87c4 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 2a11531ee6b4d..0d6a6fbff8504 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 a25810c027123f858176b3357dd69006a8f92912 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Thu, 5 Jul 2018 09:34:37 +0200 Subject: [PATCH 0282/2516] Add some details about `DefId` creation --- src/doc/rustc-dev-guide/src/lowering.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/lowering.md b/src/doc/rustc-dev-guide/src/lowering.md index 335513342c429..cc2a7b3846cc6 100644 --- a/src/doc/rustc-dev-guide/src/lowering.md +++ b/src/doc/rustc-dev-guide/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 43d5a02af4d7facc036e84d1858891e0f9638bfd Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Fri, 6 Jul 2018 14:25:34 +0200 Subject: [PATCH 0283/2516] Satisfy tidy checks --- src/doc/rustc-dev-guide/src/hir.md | 12 +++++----- src/doc/rustc-dev-guide/src/lowering.md | 23 ++++++++++--------- .../rustc-dev-guide/src/name-resolution.md | 12 +++++----- 3 files changed, 24 insertions(+), 23 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 0d6a6fbff8504..0fd2fcff56597 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/lowering.md b/src/doc/rustc-dev-guide/src/lowering.md index cc2a7b3846cc6..eddc00af96df5 100644 --- a/src/doc/rustc-dev-guide/src/lowering.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 5095b750abdf6..bba3142fc08d7 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 83adaf3db5133b04057e6efbadf69646ffed5fab Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Fri, 6 Jul 2018 14:39:24 +0200 Subject: [PATCH 0284/2516] md -> html --- src/doc/rustc-dev-guide/src/hir.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 0fd2fcff56597..40a14dc256042 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 f00994a71a3d4f114833e97072edc441dbfc92f2 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 8 Jul 2018 18:34:25 -0500 Subject: [PATCH 0285/2516] Quick fix: copy/paste error --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 4b445c924dbc7..c8fb6dd08e0e5 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 fd000066ad8b08f8b78a4d2fc4f38051ab2fa37a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 9 Jul 2018 13:28:29 -0500 Subject: [PATCH 0286/2516] Add the small amount i know about hygiene (#167) * add the small amount i know about hygiene * use en-dash --- .../rustc-dev-guide/src/macro-expansion.md | 50 +++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index df0dc7b1dc357..bb3116d405b27 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 da89f687a120d29ebd4b2e820a306405c63cd6a8 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Mon, 9 Jul 2018 05:10:27 -0700 Subject: [PATCH 0287/2516] Update mdbook Closes #138 Closes #160 --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 69b96cc732fde..29e3a2f9b612b 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 114278adc0f45c1729f5f018cad4b515b9601340 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 19:49:34 -0500 Subject: [PATCH 0288/2516] fix all the not-en-dashes --- src/doc/rustc-dev-guide/README.md | 4 +- .../src/appendix/background.md | 4 +- src/doc/rustc-dev-guide/src/compiletest.md | 2 +- src/doc/rustc-dev-guide/src/conventions.md | 6 +-- .../rustc-dev-guide/src/incrcomp-debugging.md | 2 +- src/doc/rustc-dev-guide/src/mir/borrowck.md | 2 +- src/doc/rustc-dev-guide/src/mir/index.md | 10 ++-- src/doc/rustc-dev-guide/src/mir/passes.md | 6 +-- src/doc/rustc-dev-guide/src/mir/regionck.md | 36 +++++++------- src/doc/rustc-dev-guide/src/mir/visitor.md | 2 +- src/doc/rustc-dev-guide/src/query.md | 2 +- src/doc/rustc-dev-guide/src/tests/adding.md | 8 ++-- src/doc/rustc-dev-guide/src/tests/intro.md | 48 +++++++++---------- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-checking.md | 4 +- src/doc/rustc-dev-guide/src/variance.md | 6 +-- 24 files changed, 100 insertions(+), 100 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 5dc64ed4de1fe..a01758d48a8f5 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/background.md b/src/doc/rustc-dev-guide/src/appendix/background.md index 0691319472e42..efdce4f2a66fa 100644 --- a/src/doc/rustc-dev-guide/src/appendix/background.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index cdcede33a4328..0837fb819350c 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 5b2b7b7f617d4..3f30dac73d486 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/incrcomp-debugging.md b/src/doc/rustc-dev-guide/src/incrcomp-debugging.md index 2488aa320de42..ecb29d544e4b1 100644 --- a/src/doc/rustc-dev-guide/src/incrcomp-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/borrowck.md b/src/doc/rustc-dev-guide/src/mir/borrowck.md index cd83843f89d35..d5fea6184d421 100644 --- a/src/doc/rustc-dev-guide/src/mir/borrowck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index 838048b81a4e5..ea72decdcb696 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/passes.md b/src/doc/rustc-dev-guide/src/mir/passes.md index a5b5df10a99ed..c48ef457697b3 100644 --- a/src/doc/rustc-dev-guide/src/mir/passes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/regionck.md b/src/doc/rustc-dev-guide/src/mir/regionck.md index 90f6fa2749f14..9034af8a8019b 100644 --- a/src/doc/rustc-dev-guide/src/mir/regionck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/visitor.md b/src/doc/rustc-dev-guide/src/mir/visitor.md index 265769b34c506..ad00bc3f16a19 100644 --- a/src/doc/rustc-dev-guide/src/mir/visitor.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 7ed299b74e8ad..a0c0d6282916e 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index fac13fcacfeea..a9400c59129f2 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index bc84c9721f500..69d9ed057fb22 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 03eb8ccc48ad4..e55b6ec7db2dc 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/associated-types.md b/src/doc/rustc-dev-guide/src/traits/associated-types.md index ec20985ffe308..1972a70e6b7d2 100644 --- a/src/doc/rustc-dev-guide/src/traits/associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md index 56637dace30e5..c58fe3696b73f 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md index f87de5f814f1c..1ef1da71735e6 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index 5844e8d45f4d1..93bafe33f6fd7 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/index.md b/src/doc/rustc-dev-guide/src/traits/index.md index 2dabd0b69677f..c070d1b888a6d 100644 --- a/src/doc/rustc-dev-guide/src/traits/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md index 205e9a171aa44..030e198608ed0 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-module.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md index d8b73989091b9..e37999e57bbe3 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md index 2de28ce4e3f9f..cf8c1c25a8db5 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-checking.md b/src/doc/rustc-dev-guide/src/type-checking.md index 9a161abd21115..d4f4bf1107e51 100644 --- a/src/doc/rustc-dev-guide/src/type-checking.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md index 05a286c075c1f..9fe98b4a149ee 100644 --- a/src/doc/rustc-dev-guide/src/variance.md +++ b/src/doc/rustc-dev-guide/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 dce30e99dc02a0da09c69da4cd7f2afc57906152 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 20:24:09 -0500 Subject: [PATCH 0289/2516] fix lacking spaces --- src/doc/rustc-dev-guide/src/tests/intro.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 69d9ed057fb22..bfe084618d4e4 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 fd277649839c3e2d94d770683926d8ca101062e1 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 18:44:04 -0500 Subject: [PATCH 0290/2516] define FileMap; fix #35 --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 5 +++-- src/doc/rustc-dev-guide/src/the-parser.md | 9 +++++---- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index ef7853fc6f8d6..d47cde8cd403a 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index dd451d24fcefa..e89c09e9e2304 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 3ca16b773fa6861b0ecf589ce73cc580d766661c Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 20:29:58 -0500 Subject: [PATCH 0291/2516] Attempt to address review comments --- .../rustc-dev-guide/src/appendix/code-index.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index d47cde8cd403a..1dbbec646b8a8 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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 e88f3df7298147a0c072a4e4d2d6f2dc78a7f7f9 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 10 Jul 2018 20:52:47 -0500 Subject: [PATCH 0292/2516] update definitions --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 1dbbec646b8a8..b6986c5c0a862 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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 4a4b534fd7fd1c0c303165bfb09d3c1c34aa8e80 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 14 Jul 2018 15:58:17 -0500 Subject: [PATCH 0293/2516] add a bit about buffered lints --- src/doc/rustc-dev-guide/src/diag.md | 38 +++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 67bd4829c4de6..3690d615277b3 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 57a4bd9b9a621161d1303714e40209ec13a391df Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 18:28:51 -0500 Subject: [PATCH 0294/2516] add a bit on llvm --- src/doc/rustc-dev-guide/src/codegen.md | 49 +++++++++++++++++++++++++- 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/codegen.md b/src/doc/rustc-dev-guide/src/codegen.md index f5894baa795a6..279875995a6a9 100644 --- a/src/doc/rustc-dev-guide/src/codegen.md +++ b/src/doc/rustc-dev-guide/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 c9238482872d729d92eb6619518a30e163d6070c Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 18:31:56 -0500 Subject: [PATCH 0295/2516] line length --- src/doc/rustc-dev-guide/src/codegen.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/codegen.md b/src/doc/rustc-dev-guide/src/codegen.md index 279875995a6a9..cb99e4d380444 100644 --- a/src/doc/rustc-dev-guide/src/codegen.md +++ b/src/doc/rustc-dev-guide/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 890585abf05672c3b6dd84308d30e2008e0870e1 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 15 Jul 2018 18:49:03 -0500 Subject: [PATCH 0296/2516] add notes about generating llvm ir --- .../rustc-dev-guide/src/compiler-debugging.md | 170 ++++++++++++------ 1 file changed, 117 insertions(+), 53 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index c8fb6dd08e0e5..d1171e0e06085 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 74ffa29ef3b861dcb22b583df3535f8eba24a6b0 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 15 Jul 2018 18:51:41 -0500 Subject: [PATCH 0297/2516] minor improvements --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/codegen.md | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index a41f78a1a87c4..206bf5d36f0ab 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen.md b/src/doc/rustc-dev-guide/src/codegen.md index cb99e4d380444..6e68db6ea5739 100644 --- a/src/doc/rustc-dev-guide/src/codegen.md +++ b/src/doc/rustc-dev-guide/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 d53aaa35672c5e9438aa527844be0ca892844af3 Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Thu, 9 Aug 2018 09:05:36 -0600 Subject: [PATCH 0298/2516] 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/doc/rustc-dev-guide/src/tests/adding.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index a9400c59129f2..7469755f71ca2 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 0e9d5c3ef01ea2499132922fb346c8f48f94cf0a Mon Sep 17 00:00:00 2001 From: John Renner Date: Tue, 24 Jul 2018 08:58:25 -0700 Subject: [PATCH 0299/2516] Add testing chapter --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/testing.md | 145 +++++++++++++++++++++++++ 2 files changed, 146 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/testing.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 206bf5d36f0ab..27a6e38f2e7c0 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/testing.md b/src/doc/rustc-dev-guide/src/testing.md new file mode 100644 index 0000000000000..abe6849a78208 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 9e83f15ad3f0da2481e59154631021dcd67106eb Mon Sep 17 00:00:00 2001 From: John Renner Date: Tue, 24 Jul 2018 10:41:01 -0700 Subject: [PATCH 0300/2516] Shorten line length --- src/doc/rustc-dev-guide/src/testing.md | 49 +++++++++++++++----------- 1 file changed, 29 insertions(+), 20 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/testing.md b/src/doc/rustc-dev-guide/src/testing.md index abe6849a78208..3c93ad619ee21 100644 --- a/src/doc/rustc-dev-guide/src/testing.md +++ b/src/doc/rustc-dev-guide/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 955d0f913d09e1c4d656b43dcb0366f65cc96357 Mon Sep 17 00:00:00 2001 From: John Renner Date: Tue, 7 Aug 2018 10:59:52 -0700 Subject: [PATCH 0301/2516] More descriptive name for #[test] implementation --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- .../rustc-dev-guide/src/{testing.md => test-implementation.md} | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename src/doc/rustc-dev-guide/src/{testing.md => test-implementation.md} (100%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 27a6e38f2e7c0..ca3b4c0203292 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/testing.md b/src/doc/rustc-dev-guide/src/test-implementation.md similarity index 100% rename from src/doc/rustc-dev-guide/src/testing.md rename to src/doc/rustc-dev-guide/src/test-implementation.md From 1e4bf1dd58f4e9a771b99bfb89182ff1696e0740 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 18 Aug 2018 12:54:42 -0700 Subject: [PATCH 0302/2516] 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/doc/rustc-dev-guide/src/compiletest.md | 10 --------- src/doc/rustc-dev-guide/src/conventions.md | 23 +++++---------------- src/doc/rustc-dev-guide/src/tests/adding.md | 4 ---- 3 files changed, 5 insertions(+), 32 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 0837fb819350c..40d06136eb1db 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 3f30dac73d486..93c5c44be7964 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 7469755f71ca2..ee264747a8d90 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 8386481619bb04d5e6fe830d9b8c9197502eebb6 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Fri, 6 Jul 2018 14:53:53 +0200 Subject: [PATCH 0303/2516] Explain existential types --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../rustc-dev-guide/src/existential-types.md | 48 +++++++++++++++++++ 2 files changed, 49 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/existential-types.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index ca3b4c0203292..981da5c1eefc6 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/existential-types.md b/src/doc/rustc-dev-guide/src/existential-types.md new file mode 100644 index 0000000000000..4c5ebb75c88a2 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 cacbda24e8b68be92570e18f2c79288b733780c4 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Wed, 1 Aug 2018 18:35:17 +0200 Subject: [PATCH 0304/2516] Update existential-types.md --- src/doc/rustc-dev-guide/src/existential-types.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/existential-types.md b/src/doc/rustc-dev-guide/src/existential-types.md index 4c5ebb75c88a2..3e4a49210fcdd 100644 --- a/src/doc/rustc-dev-guide/src/existential-types.md +++ b/src/doc/rustc-dev-guide/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 32fe7bd6d2430727ae459464178cd0e14e68fcb5 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 7 Aug 2018 08:38:21 -0400 Subject: [PATCH 0305/2516] add rust,ignore to code snippets --- src/doc/rustc-dev-guide/src/existential-types.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/existential-types.md b/src/doc/rustc-dev-guide/src/existential-types.md index 3e4a49210fcdd..ef20167c18391 100644 --- a/src/doc/rustc-dev-guide/src/existential-types.md +++ b/src/doc/rustc-dev-guide/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 6ebc0cd09bcc3f9e5fa76ba7de689f3914a444d1 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 0306/2516] Rename CodeMap and FileMap to SourceMap and SourceFile. Those types were renamed in https://github.com/rust-lang/rust/pull/52953 --- .../rustc-dev-guide/src/appendix/code-index.md | 4 ++-- src/doc/rustc-dev-guide/src/diag.md | 16 ++++++++-------- src/doc/rustc-dev-guide/src/rustc-driver.md | 4 ++-- src/doc/rustc-dev-guide/src/the-parser.md | 10 +++++----- 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index b6986c5c0a862..140b182b19708 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 3690d615277b3..3d9a6fc37e9ee 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 1550b14e9bb16..39794983674d8 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index e89c09e9e2304..62b43c0eee9ff 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 88d9da22c781664cf785c06489813278a95ebd3a 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 0307/2516] Fix lines over 80 columns. --- src/doc/rustc-dev-guide/src/diag.md | 6 +++--- src/doc/rustc-dev-guide/src/the-parser.md | 7 ++++--- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 3d9a6fc37e9ee..b30ec2ecafcb3 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index 62b43c0eee9ff..ac902d91547a4 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 8958f2b14d38d176ac32275fc630e70e3f028fdc 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 0308/2516] address review comment --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 140b182b19708..75d35c6c5d514 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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 7e0b8f6878a99a3d866af714d541af6b8d039a33 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 09:23:14 -0400 Subject: [PATCH 0309/2516] sprinkle links to rustdoc through the HIR explanation --- src/doc/rustc-dev-guide/src/hir.md | 87 ++++++++++++++++++++---------- 1 file changed, 58 insertions(+), 29 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 40a14dc256042..171319011deb3 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 422ea04f746aa3c1dd3598bba7671f7d767519bf Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 09:58:32 -0400 Subject: [PATCH 0310/2516] tweak long line --- src/doc/rustc-dev-guide/src/hir.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 171319011deb3..a5e99e8b3b520 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 383a28ac4935328ca71b148c2b912525a951c51a Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:00:31 -0400 Subject: [PATCH 0311/2516] add a section about the compiler team --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/compiler-team.md | 100 +++++++++++++++++++ 2 files changed, 101 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/compiler-team.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 981da5c1eefc6..8de0e71caf9d4 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md new file mode 100644 index 0000000000000..89e95e2c3fe71 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 0f89a934fe3c6c8444d63eb29b51817b44d154b4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:59:29 -0400 Subject: [PATCH 0312/2516] adjust long lines --- src/doc/rustc-dev-guide/src/compiler-team.md | 36 ++++++++++++-------- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index 89e95e2c3fe71..d7ee98d3003bd 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 ac07e17a413fdc8bd3b97eb03900f2f6a56d4c79 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 14:46:03 -0400 Subject: [PATCH 0313/2516] fix various minor points --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/compiler-team.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 8de0e71caf9d4..1cb9ea599fc7b 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index d7ee98d3003bd..ad8ac292f2061 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 cacc3f217e5839ed596bb3fe406e01eb4c8a043f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 14:48:16 -0400 Subject: [PATCH 0314/2516] includ some notes on finding bugs --- src/doc/rustc-dev-guide/src/compiler-team.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index ad8ac292f2061..45883e9d1b213 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 4212f0d8ad35cf849e8eb21631a0a146b32e1164 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 14:50:29 -0400 Subject: [PATCH 0315/2516] note about discussion channels --- src/doc/rustc-dev-guide/src/compiler-team.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index 45883e9d1b213..a6328198ca5ed 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 11dc8e8967dff8cc5411c2125f80e4cebc77d448 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 0316/2516] No copyright notices on new tests --- src/doc/rustc-dev-guide/src/tests/adding.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index ee264747a8d90..dca224fffe511 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 91fee4d0f7eafa912889eb2dabad8841c0998902 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 0317/2516] Write in English --- src/doc/rustc-dev-guide/src/tests/adding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index dca224fffe511..b9f05b9dd785b 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 14e55b3446ecd6cabaf6ad03300379696c1655ef Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:57:51 -0400 Subject: [PATCH 0318/2516] add a section about profiling with perf --- src/doc/rustc-dev-guide/src/SUMMARY.md | 4 +- src/doc/rustc-dev-guide/src/profiling.md | 9 + .../src/profiling/with_perf.md | 294 ++++++++++++++++++ 3 files changed, 306 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/src/profiling.md create mode 100644 src/doc/rustc-dev-guide/src/profiling/with_perf.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 1cb9ea599fc7b..ad8a826237498 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md new file mode 100644 index 0000000000000..f6771b07bb00d --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md new file mode 100644 index 0000000000000..dc767c9a5f623 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 01ce54cd3b094ea0c21f65f7e0d4e9e1090278e9 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 13:46:13 -0400 Subject: [PATCH 0319/2516] various nits from mark-i-m --- .../src/profiling/with_perf.md | 38 ++++++++++--------- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index dc767c9a5f623..94ce6f92f61cf 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 e708568d0559047a9745ed46079308985ed761ce Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 13:49:29 -0400 Subject: [PATCH 0320/2516] switch to em-dash --- .../src/profiling/with_perf.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 94ce6f92f61cf..9f0554e5e1c71 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 ff5e25fd2ef021d645d5e475f135d91f7165f6c2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 13:50:06 -0400 Subject: [PATCH 0321/2516] fix long lines --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 9f0554e5e1c71..85dc8efd6599e 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 3b833916f794ad20e57f2bd95546d309d0a96913 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 10:03:56 -0400 Subject: [PATCH 0322/2516] be consistent about bash snippets --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 85dc8efd6599e..61720c3b4ccbb 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 9c3d2ab8e79881236dc5ccf7a6b15d70786b8d08 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 10:55:46 -0400 Subject: [PATCH 0323/2516] say function, not fn --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 61720c3b4ccbb..f0f6aada96cfe 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 776fc2ad18e129ef6d6d7a7c8fc18d276c7c6c66 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 10:59:05 -0400 Subject: [PATCH 0324/2516] link to build-and-run, fix em-dash --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 8 ++++++++ src/doc/rustc-dev-guide/src/profiling/with_perf.md | 4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 557fc9148ed8b..3ad9a52aed6cc 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index f0f6aada96cfe..740b0a2633a2d 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 1bd737675aa3a8c29a8eb660bdde9e2500a6ed4e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:00:09 -0400 Subject: [PATCH 0325/2516] don't write `rust-prof` bur rather ` --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 740b0a2633a2d..683b61d2e1e49 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 90bac20aa75203e5a20f2e0f8e51ad42974624fc Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:01:29 -0400 Subject: [PATCH 0326/2516] update with njn's insight --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 683b61d2e1e49..cec17d344ea87 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 f8e02179816da1d23fb74dc00bc5550c39179188 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:07:56 -0400 Subject: [PATCH 0327/2516] add a note about the collector executable --- .../src/profiling/with_perf.md | 32 +++++++++++++++++-- 1 file changed, 29 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index cec17d344ea87..498dc139619e8 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 f62bcbaa1f5f33a0e429c3d36ca2a71f3262c531 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:29:45 -0400 Subject: [PATCH 0328/2516] fix link --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 498dc139619e8..be6a8a477b266 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 e40767296a7935302ac4f84fe900186e41622e96 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 17:21:35 -0400 Subject: [PATCH 0329/2516] links are always relative to root or what? --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index be6a8a477b266..c851d1a23e526 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 9799b0b3acb60e6658e7b6b8dd15f0d4dd7c48b7 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 10 Sep 2018 14:38:11 -0400 Subject: [PATCH 0330/2516] fix various bash snippets --- .../rustc-dev-guide/src/profiling/with_perf.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index c851d1a23e526..7d8276cedfbd2 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 2468801313004fd704ddc4990b115df0b8c74927 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Mon, 10 Sep 2018 23:43:51 +0200 Subject: [PATCH 0331/2516] 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/doc/rustc-dev-guide/src/tests/running.md | 22 +++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index e55b6ec7db2dc..fdc603a548e55 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 d6a2d84c53b5446f6dc9f8d1af04f3165161fdce Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 11:35:37 -0400 Subject: [PATCH 0332/2516] document keep-stage1 --- .../src/how-to-build-and-run.md | 134 +++++++++++++----- 1 file changed, 100 insertions(+), 34 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 3ad9a52aed6cc..749340d7b86ea 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 038232d8afd03e1208639af1808aa4948ad6d1fc Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:46:10 -0400 Subject: [PATCH 0333/2516] wrap long lines --- .../rustc-dev-guide/src/how-to-build-and-run.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 749340d7b86ea..59c31491e1e2a 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 b8abcaa6583a87da2e245ff6921a8e34d4caa290 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:48:54 -0400 Subject: [PATCH 0334/2516] note about why stage1/stage2 are different --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 59c31491e1e2a..f6c26ddf19736 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 1dcc3df66dc19b2f0b0844ecd5223b4fb83ad9cf Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:49:16 -0400 Subject: [PATCH 0335/2516] fix typos --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index f6c26ddf19736..aef5b66b8e840 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 2a45a09a18dc4e131e8764d8a8971e3696e89158 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:13:59 -0400 Subject: [PATCH 0336/2516] fix typo, add link --- .../src/how-to-build-and-run.md | 32 ++++++++++--------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index aef5b66b8e840..2285b26853577 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 8ca5450de8ceced9e429df34f6d9adcbf24f2c87 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:15:17 -0400 Subject: [PATCH 0337/2516] fix some more typos --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 2285b26853577..17c883ffc8012 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 6010623cd4a36398450aedb0742dce75ddd6b251 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:16:20 -0400 Subject: [PATCH 0338/2516] remove silly `note:` --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 17c883ffc8012..a4e6cc0f05dee 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 f081c66333c1c44cfcfb4e65aa5d42872c1f619e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 11 Sep 2018 12:02:46 -0400 Subject: [PATCH 0339/2516] wrap long lines --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index a4e6cc0f05dee..66ba8efda8a10 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 a56b3116aebf382194278880938de8efab434d1f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 11 Sep 2018 16:22:15 -0400 Subject: [PATCH 0340/2516] wrap lines in `running.md` --- src/doc/rustc-dev-guide/src/tests/running.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index fdc603a548e55..d410b79c3df14 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 d8089ff4bd66ae271b3b8a199a10d388ad551510 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 09:29:38 -0400 Subject: [PATCH 0341/2516] rearrange to promote the borrow checker into its own section --- src/doc/rustc-dev-guide/src/SUMMARY.md | 4 ++-- .../rustc-dev-guide/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/doc/rustc-dev-guide/src/{mir/borrowck.md => borrow_check.md} (100%) rename src/doc/rustc-dev-guide/src/{mir/regionck.md => borrow_check/region_inference.md} (100%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index ad8a826237498..e9e2ffaeabdd4 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/borrowck.md b/src/doc/rustc-dev-guide/src/borrow_check.md similarity index 100% rename from src/doc/rustc-dev-guide/src/mir/borrowck.md rename to src/doc/rustc-dev-guide/src/borrow_check.md diff --git a/src/doc/rustc-dev-guide/src/mir/regionck.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md similarity index 100% rename from src/doc/rustc-dev-guide/src/mir/regionck.md rename to src/doc/rustc-dev-guide/src/borrow_check/region_inference.md From 5732b7cf1283ce4b15f5cf520743bc9e5fb71e2d Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 09:57:35 -0400 Subject: [PATCH 0342/2516] add content --- src/doc/rustc-dev-guide/src/SUMMARY.md | 3 + src/doc/rustc-dev-guide/src/borrow_check.md | 48 ++++--- .../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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md create mode 100644 src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md create mode 100644 src/doc/rustc-dev-guide/src/borrow_check/type_check.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index e9e2ffaeabdd4..338cb7fe12af5 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check.md b/src/doc/rustc-dev-guide/src/borrow_check.md index d5fea6184d421..07095f20a830a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md new file mode 100644 index 0000000000000..6bc8cc476b18e --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md new file mode 100644 index 0000000000000..9d5dc3ed9f09b --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 9034af8a8019b..47b21b0d25560 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/type_check.md b/src/doc/rustc-dev-guide/src/borrow_check/type_check.md new file mode 100644 index 0000000000000..10d961554f63b --- /dev/null +++ b/src/doc/rustc-dev-guide/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 72c041af5c9fded3b34a8177df69b209f127a23c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:24:24 -0400 Subject: [PATCH 0343/2516] address nits --- src/doc/rustc-dev-guide/src/borrow_check.md | 6 +++--- .../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/doc/rustc-dev-guide/src/borrow_check.md b/src/doc/rustc-dev-guide/src/borrow_check.md index 07095f20a830a..40858b1b4acf3 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md index 6bc8cc476b18e..3801a5b8c7b0c 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index 9d5dc3ed9f09b..7a1239db1200a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/type_check.md b/src/doc/rustc-dev-guide/src/borrow_check/type_check.md index 10d961554f63b..ee955d971705f 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/type_check.md +++ b/src/doc/rustc-dev-guide/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 efdbbf70cb0d34ea1cc9b532caee4e938e15fe58 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 17:23:47 -0400 Subject: [PATCH 0344/2516] fix glossary links --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index bfc2c0d22ee07..42315536a4a16 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 3d96e531bbab24c29e380acc717fce6ad7adbf24 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 10 Sep 2018 14:34:48 -0400 Subject: [PATCH 0345/2516] bump max line length to 100 otherwise our summary.md doesn't fit --- src/doc/rustc-dev-guide/.travis.yml | 2 +- src/doc/rustc-dev-guide/ci/check_line_lengths.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index d7f8f8f42f560..55ea2058764c4 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/check_line_lengths.sh b/src/doc/rustc-dev-guide/ci/check_line_lengths.sh index 91f199b7e3654..5b7b12d3e5ea9 100755 --- a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh +++ b/src/doc/rustc-dev-guide/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 59e7c8bf8560fbc631491aa0b7d7155849db6738 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 11 Sep 2018 16:43:36 -0400 Subject: [PATCH 0346/2516] 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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md index 3801a5b8c7b0c..d1cd41e0ff6bb 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index 7a1239db1200a..c9e22a81c4c81 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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 7fe451618b6f10b8fe1ae84f637859057f3412a3 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 11 Sep 2018 07:36:49 +0200 Subject: [PATCH 0347/2516] Fix typos These were fixed using [codespell](https://github.com/codespell-project/codespell). --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 4 ++-- .../rustc-dev-guide/src/borrow_check/region_inference.md | 4 ++-- src/doc/rustc-dev-guide/src/codegen.md | 6 +++--- src/doc/rustc-dev-guide/src/compiletest.md | 2 +- src/doc/rustc-dev-guide/src/lowering.md | 2 +- src/doc/rustc-dev-guide/src/macro-expansion.md | 6 +++--- src/doc/rustc-dev-guide/src/rustdoc.md | 2 +- src/doc/rustc-dev-guide/src/traits/canonicalization.md | 2 +- src/doc/rustc-dev-guide/src/traits/lowering-rules.md | 2 +- src/doc/rustc-dev-guide/src/traits/resolution.md | 2 +- 10 files changed, 16 insertions(+), 16 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 42315536a4a16..44ac26ca3fc3d 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 47b21b0d25560..2cd6066ec0d66 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen.md b/src/doc/rustc-dev-guide/src/codegen.md index 6e68db6ea5739..766dfff59d8c9 100644 --- a/src/doc/rustc-dev-guide/src/codegen.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 40d06136eb1db..3cfb943b07ed6 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/lowering.md b/src/doc/rustc-dev-guide/src/lowering.md index eddc00af96df5..2504ed4911f59 100644 --- a/src/doc/rustc-dev-guide/src/lowering.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index bb3116d405b27..b03a218c266ea 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 76a8b28ce7da3..318a8e2e12cd6 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md index 1ef1da71735e6..2cc35d8994d62 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md index e37999e57bbe3..41c9625f66b33 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md index e33e0c8ec70e3..987d9a28db62a 100644 --- a/src/doc/rustc-dev-guide/src/traits/resolution.md +++ b/src/doc/rustc-dev-guide/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 0460a76b7838dc81601639f12d4525b357485020 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 11 Sep 2018 07:47:13 +0200 Subject: [PATCH 0348/2516] Fix line lengths --- src/doc/rustc-dev-guide/src/macro-expansion.md | 6 +++--- src/doc/rustc-dev-guide/src/tests/running.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index b03a218c266ea..c62301247a62a 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index d410b79c3df14..778fd00ec1e23 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 131262f749935849e015904b8d49ab9a41d0c7f7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 20 Aug 2018 11:15:35 -0500 Subject: [PATCH 0349/2516] use mdbook 0.2 --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 29e3a2f9b612b..dc413f68c1976 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 a99929a4d0663c95adb675aea9304b10eddbcefa Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 20 Aug 2018 11:19:02 -0500 Subject: [PATCH 0350/2516] update readme with mdbook version --- src/doc/rustc-dev-guide/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index a01758d48a8f5..57b3a0ea4ab1b 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 beceb036c059a8dc12f9d3542288131fd7a618cd Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 8 Sep 2018 21:35:59 -0500 Subject: [PATCH 0351/2516] Fix all the links to be relative for mdbook 2 --- .../src/appendix/background.md | 2 +- .../src/appendix/code-index.md | 26 ++++----- .../rustc-dev-guide/src/appendix/glossary.md | 58 +++++++++---------- .../src/borrow_check/region_inference.md | 8 +-- src/doc/rustc-dev-guide/src/mir/index.md | 6 +- src/doc/rustc-dev-guide/src/mir/passes.md | 4 +- src/doc/rustc-dev-guide/src/tests/intro.md | 8 +-- .../src/traits/associated-types.md | 4 +- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/index.md | 14 ++--- .../src/traits/lowering-module.md | 4 +- .../src/traits/lowering-rules.md | 10 ++-- .../src/traits/lowering-to-logic.md | 4 +- .../rustc-dev-guide/src/traits/resolution.md | 4 +- 18 files changed, 103 insertions(+), 103 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/background.md b/src/doc/rustc-dev-guide/src/appendix/background.md index efdce4f2a66fa..dbfe6a3dbe826 100644 --- a/src/doc/rustc-dev-guide/src/appendix/background.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 75d35c6c5d514..e1bde6863a307 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 44ac26ca3fc3d..5c7d827415769 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 2cd6066ec0d66..5a09f0bb0cd09 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index ea72decdcb696..d69606d66f466 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/passes.md b/src/doc/rustc-dev-guide/src/mir/passes.md index c48ef457697b3..7dc1249a0f574 100644 --- a/src/doc/rustc-dev-guide/src/mir/passes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index bfe084618d4e4..8b2937f9f6e69 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/associated-types.md b/src/doc/rustc-dev-guide/src/traits/associated-types.md index 1972a70e6b7d2..b8ac7f8b9d32e 100644 --- a/src/doc/rustc-dev-guide/src/traits/associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/caching.md b/src/doc/rustc-dev-guide/src/traits/caching.md index 228ff0917ec75..f8453950959e6 100644 --- a/src/doc/rustc-dev-guide/src/traits/caching.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md index c58fe3696b73f..876c5d8a6d78e 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md index 2cc35d8994d62..df0c4a2b9366b 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonicalization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index e737edcd912d7..818e1dc4ddbea 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index 93bafe33f6fd7..5aa3755ad1f79 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/index.md b/src/doc/rustc-dev-guide/src/traits/index.md index c070d1b888a6d..c5afb280bdaed 100644 --- a/src/doc/rustc-dev-guide/src/traits/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md index 030e198608ed0..c9c4accc1c4e8 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-module.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md index 41c9625f66b33..218164c0f75ae 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md index cf8c1c25a8db5..a0490adf351c8 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md index 987d9a28db62a..2ba4516779cf6 100644 --- a/src/doc/rustc-dev-guide/src/traits/resolution.md +++ b/src/doc/rustc-dev-guide/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 863f90a27d3e8d7eed21d7deee5f43f26ff823fb Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 8 Sep 2018 21:37:07 -0500 Subject: [PATCH 0352/2516] use new mdbook-linkcheck version --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index dc413f68c1976..eca1b5cdff195 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 04589fcbdcb5e12227399912f02f5e06f887e27d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 8 Sep 2018 21:38:07 -0500 Subject: [PATCH 0353/2516] update readme --- src/doc/rustc-dev-guide/README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 57b3a0ea4ab1b..2a59a40bbf24d 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 fcccfa805991e5cffb405efb36545e1292ca2863 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 12 Sep 2018 21:55:06 -0500 Subject: [PATCH 0354/2516] check web links --- src/doc/rustc-dev-guide/book.toml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index ecbe513b7cbe0..8c13fa1aa3c64 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 eddef1d97bf82812a8c1ff0419a9e6d3ace02989 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 12 Sep 2018 22:01:44 -0500 Subject: [PATCH 0355/2516] fix the last link --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 7d8276cedfbd2..25889940029c3 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 6d54b23c44cb2e12d8d9044cf3837297abb93c7f Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 21 Sep 2018 14:36:11 -0500 Subject: [PATCH 0356/2516] don't check crates.io links --- src/doc/rustc-dev-guide/book.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 8c13fa1aa3c64..93e40ef50554c 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/book.toml @@ -9,3 +9,4 @@ description = "A guide to developing rustc" [output.linkcheck] follow-web-links = true +exclude = [ "crates\\.io" ] From 6022a84bd2d7673b9ffc7a0686e365aab6d6c385 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 21 Sep 2018 15:09:45 -0500 Subject: [PATCH 0357/2516] Fix all the links! --- src/doc/rustc-dev-guide/book.toml | 2 +- .../src/appendix/stupid-stats.md | 17 +++++++++++------ src/doc/rustc-dev-guide/src/const-eval.md | 2 +- src/doc/rustc-dev-guide/src/diag.md | 2 +- src/doc/rustc-dev-guide/src/miri.md | 2 +- src/doc/rustc-dev-guide/src/tests/intro.md | 2 +- .../src/traits/chalk-overview.md | 2 +- 7 files changed, 17 insertions(+), 12 deletions(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 93e40ef50554c..b9092a969c229 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md index 842a2a3286a66..a36cac42ba51c 100644 --- a/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/const-eval.md b/src/doc/rustc-dev-guide/src/const-eval.md index 70c946f176a68..1f801fb22b10d 100644 --- a/src/doc/rustc-dev-guide/src/const-eval.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index b30ec2ecafcb3..936420ab6ecb4 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index be9587408ceac..a3c7b3ff4a2bc 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 8b2937f9f6e69..4d509f3a8ed98 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 818e1dc4ddbea..3473a0764381d 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 903991edcefbe8a4b0bc0397e9e48343a28ad77b Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 21 Sep 2018 15:28:41 -0500 Subject: [PATCH 0358/2516] use the right version of mdbook linkcheck --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index eca1b5cdff195..80f8de4e8a513 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 13a681629b7049190f0444899e366c58b33d8401 Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Thu, 27 Sep 2018 09:27:30 -0600 Subject: [PATCH 0359/2516] Document no-system-llvm --- src/doc/rustc-dev-guide/src/tests/adding.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index b9f05b9dd785b..1120315b9ebfc 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 27c18dc09bd6326ecc21557cec0c79a5df699fd7 Mon Sep 17 00:00:00 2001 From: Alcaro Date: Sat, 29 Sep 2018 00:03:40 +0200 Subject: [PATCH 0360/2516] conventions: Fix semicolon/colon typo --- src/doc/rustc-dev-guide/src/conventions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 93c5c44be7964..d392ebd572220 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 1b8804a2ce0e69c6da5df34ea775c40b55c0722e Mon Sep 17 00:00:00 2001 From: David Sanders Date: Fri, 28 Sep 2018 18:47:52 -0700 Subject: [PATCH 0361/2516] Typo nits #181 (#205) --- src/doc/rustc-dev-guide/src/hir.md | 2 +- src/doc/rustc-dev-guide/src/lowering.md | 4 ++-- src/doc/rustc-dev-guide/src/traits/canonical-queries.md | 2 +- src/doc/rustc-dev-guide/src/traits/canonicalization.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index a5e99e8b3b520..e6bca7f37d029 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/lowering.md b/src/doc/rustc-dev-guide/src/lowering.md index 2504ed4911f59..c3a1a96ccf2ae 100644 --- a/src/doc/rustc-dev-guide/src/lowering.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md index 876c5d8a6d78e..cbf7d880d0d59 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md index df0c4a2b9366b..62c4d9f7483de 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonicalization.md +++ b/src/doc/rustc-dev-guide/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 93da487d8fc764665d0477cef6860ac9960d4fef Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 6 Sep 2018 20:13:36 -0400 Subject: [PATCH 0362/2516] issue-130 copy contents related x.py from rust-forge --- .../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/doc/rustc-dev-guide/src/tests/running.md | 23 +++++++++ src/doc/rustc-dev-guide/src/what-is-x-py.md | 42 +++++++++++++++ 6 files changed, 201 insertions(+), 2 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md create mode 100644 src/doc/rustc-dev-guide/src/compiler-benchmarking.md create mode 100644 src/doc/rustc-dev-guide/src/compiler-documenting.md create mode 100644 src/doc/rustc-dev-guide/src/what-is-x-py.md diff --git a/src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md b/src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md new file mode 100644 index 0000000000000..472c074a30db8 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-benchmarking.md b/src/doc/rustc-dev-guide/src/compiler-benchmarking.md new file mode 100644 index 0000000000000..1ce1e05ac4786 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-documenting.md b/src/doc/rustc-dev-guide/src/compiler-documenting.md new file mode 100644 index 0000000000000..919914e98848d --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 66ba8efda8a10..07a5eeb4dfdad 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 778fd00ec1e23..970829cce7e5f 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/what-is-x-py.md b/src/doc/rustc-dev-guide/src/what-is-x-py.md new file mode 100644 index 0000000000000..315a3f8210a03 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 8708c9b4597012cb56dae18bec0c69ea81fb6f59 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Tue, 18 Sep 2018 17:29:59 -0400 Subject: [PATCH 0363/2516] issue-130 incorporate the review comments --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 + .../build-install-distribution-artifacts.md | 15 +-- .../src/compiler-documenting.md | 25 +++-- .../src/how-to-build-and-run.md | 92 ++++++++++++++----- src/doc/rustc-dev-guide/src/tests/running.md | 10 +- src/doc/rustc-dev-guide/src/what-is-x-py.md | 42 --------- 6 files changed, 100 insertions(+), 86 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/what-is-x-py.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 338cb7fe12af5..213a645aba490 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md b/src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md index 472c074a30db8..89b1422a0d6b2 100644 --- a/src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-documenting.md b/src/doc/rustc-dev-guide/src/compiler-documenting.md index 919914e98848d..61d65f3764132 100644 --- a/src/doc/rustc-dev-guide/src/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 07a5eeb4dfdad..c11d269bd5aa5 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 970829cce7e5f..07030c7991dbb 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/what-is-x-py.md b/src/doc/rustc-dev-guide/src/what-is-x-py.md deleted file mode 100644 index 315a3f8210a03..0000000000000 --- a/src/doc/rustc-dev-guide/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 5ad3ed30bdea9c5c49ab26ecfd833292fff90431 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Wed, 26 Sep 2018 10:32:50 -0400 Subject: [PATCH 0364/2516] issue-130 updated the review comments --- .../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/doc/rustc-dev-guide/src/tests/running.md | 49 ++++++++++--------- 5 files changed, 37 insertions(+), 78 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/compiler-benchmarking.md diff --git a/src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md b/src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md index 89b1422a0d6b2..521c441a2a5c1 100644 --- a/src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-benchmarking.md b/src/doc/rustc-dev-guide/src/compiler-benchmarking.md deleted file mode 100644 index 1ce1e05ac4786..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-documenting.md b/src/doc/rustc-dev-guide/src/compiler-documenting.md index 61d65f3764132..fceb73c911005 100644 --- a/src/doc/rustc-dev-guide/src/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index c11d269bd5aa5..eb2f8a6634b9d 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 07030c7991dbb..f8889c8a4b393 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 12e5802e08754b6a36b183cda8c150a37653fa48 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Fri, 28 Sep 2018 23:01:47 -0400 Subject: [PATCH 0365/2516] updated with review comments --- .../src/build-install-distribution-artifacts.md | 13 ++++++++++--- src/doc/rustc-dev-guide/src/compiler-documenting.md | 3 ++- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md b/src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md index 521c441a2a5c1..7430ffb9b8dc0 100644 --- a/src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-documenting.md b/src/doc/rustc-dev-guide/src/compiler-documenting.md index fceb73c911005..bf63c012055ac 100644 --- a/src/doc/rustc-dev-guide/src/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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 427c5bf0040307e1c55a4795b11b792a6caf573a Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 13 Oct 2018 11:35:53 -0500 Subject: [PATCH 0366/2516] Update a few parts of the readme --- src/doc/rustc-dev-guide/README.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 2a59a40bbf24d..45c7503fec573 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 829028c03a13cfcd25b3a457850f8fbf16ef2832 Mon Sep 17 00:00:00 2001 From: Collins Abitekaniza Date: Sat, 20 Oct 2018 01:19:52 +0300 Subject: [PATCH 0367/2516] fix typo in build instructions --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index eb2f8a6634b9d..4315cd70861fe 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 dfa7d83a3861e3ca1863bd5b657f7fb4e4298719 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 19 Oct 2018 16:19:27 -0500 Subject: [PATCH 0368/2516] Fix typo --- .../src/borrow_check/moves_and_initialization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md index d1cd41e0ff6bb..d1530d6c09056 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md +++ b/src/doc/rustc-dev-guide/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 7b81c746702e958d647f12644f509634e1039f51 Mon Sep 17 00:00:00 2001 From: scalexm Date: Tue, 16 Oct 2018 14:55:03 +0200 Subject: [PATCH 0369/2516] Polish lowering chapters and update rules --- .../src/traits/associated-types.md | 21 +++-- .../src/traits/goals-and-clauses.md | 84 +++++++++++++++---- src/doc/rustc-dev-guide/src/traits/index.md | 14 ++++ .../src/traits/lowering-rules.md | 36 ++++---- 4 files changed, 116 insertions(+), 39 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/associated-types.md b/src/doc/rustc-dev-guide/src/traits/associated-types.md index b8ac7f8b9d32e..3330ce80993d9 100644 --- a/src/doc/rustc-dev-guide/src/traits/associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index 5aa3755ad1f79..8cc1bc7fd8208 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/index.md b/src/doc/rustc-dev-guide/src/traits/index.md index c5afb280bdaed..053a26babb291 100644 --- a/src/doc/rustc-dev-guide/src/traits/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md index 218164c0f75ae..88a61ac4fa3f5 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md +++ b/src/doc/rustc-dev-guide/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 a041e9d1eebc62581d26fe067d464bbcebd1b0b6 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 21 Oct 2018 18:05:32 +0200 Subject: [PATCH 0370/2516] Add an apostrophe Co-Authored-By: scalexm --- src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index 8cc1bc7fd8208..494ec5b8591ec 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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 cafa8d8198845a88ced9973371ced7aca0118c1d Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 21 Oct 2018 18:05:51 +0200 Subject: [PATCH 0371/2516] Fix typo Co-Authored-By: scalexm --- src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index 494ec5b8591ec..fb12c5a41a2e3 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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 76027767ecd05ccdc2b405c0db2e27930835fa51 Mon Sep 17 00:00:00 2001 From: scalexm Date: Sun, 21 Oct 2018 18:07:25 +0200 Subject: [PATCH 0372/2516] Change wording --- src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index fb12c5a41a2e3..8f1ffa4882200 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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 ef4f1414c25fadbfbf30dc70360e67b9831798ed Mon Sep 17 00:00:00 2001 From: scalexm Date: Fri, 19 Oct 2018 15:20:41 +0200 Subject: [PATCH 0373/2516] Write implied bounds chapter --- .../src/traits/implied-bounds.md | 501 +++++++++++++++++- 1 file changed, 496 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/implied-bounds.md b/src/doc/rustc-dev-guide/src/traits/implied-bounds.md index 26a63bf327162..1feb84e3b5b80 100644 --- a/src/doc/rustc-dev-guide/src/traits/implied-bounds.md +++ b/src/doc/rustc-dev-guide/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 9ae0cba39f7cfd08b1183fc5d5bfd09070f3dd1c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 21 Oct 2018 18:09:00 +0200 Subject: [PATCH 0374/2516] 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/doc/rustc-dev-guide/src/traits/implied-bounds.md b/src/doc/rustc-dev-guide/src/traits/implied-bounds.md index 1feb84e3b5b80..6f033e1b1fcae 100644 --- a/src/doc/rustc-dev-guide/src/traits/implied-bounds.md +++ b/src/doc/rustc-dev-guide/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 70bc5da5899cec046566796c561b39e3fa9f4a3f Mon Sep 17 00:00:00 2001 From: scalexm Date: Sun, 21 Oct 2018 18:30:07 +0200 Subject: [PATCH 0375/2516] Clarify wording --- .../src/traits/implied-bounds.md | 20 ++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/implied-bounds.md b/src/doc/rustc-dev-guide/src/traits/implied-bounds.md index 6f033e1b1fcae..f32c9d0cbb921 100644 --- a/src/doc/rustc-dev-guide/src/traits/implied-bounds.md +++ b/src/doc/rustc-dev-guide/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 d40622447e1d832d58c5e6cb104d890551c93b88 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 22 Oct 2018 12:48:58 -0500 Subject: [PATCH 0376/2516] Add a note on bisecting --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index d1171e0e06085..aca7f7424b8c9 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 a15bfaba5e0c7b7d55ec41cf992c321afa4ca702 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Wed, 24 Oct 2018 15:16:12 -0400 Subject: [PATCH 0377/2516] issue_100_4 Updated the rustc documentation location --- src/doc/rustc-dev-guide/src/compiler-documenting.md | 12 +++++++++--- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 6 ++++++ 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-documenting.md b/src/doc/rustc-dev-guide/src/compiler-documenting.md index bf63c012055ac..97636fad5b4bb 100644 --- a/src/doc/rustc-dev-guide/src/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 4315cd70861fe..62461d3efdbd0 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 3a1ba5c652b3294e90ba1f30dada63cdc40fde63 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 0378/2516] clean up skolemiza in glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 5c7d827415769..04d35777f83b3 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 04bb8d65f48b15d4de7d08db8caf3e66662a1877 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 0379/2516] clean up skolemiza in borrow_ck --- .../src/borrow_check/region_inference.md | 82 +++++++++---------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 5a09f0bb0cd09..617133000e5f0 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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 244a3fe47fa34a8f534cff406c9542e1ba9d05f0 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 0380/2516] clean up skolemiza in traits --- .../src/traits/associated-types.md | 2 +- src/doc/rustc-dev-guide/src/traits/caching.md | 6 ++-- src/doc/rustc-dev-guide/src/traits/hrtb.md | 28 +++++++++---------- 3 files changed, 18 insertions(+), 18 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/associated-types.md b/src/doc/rustc-dev-guide/src/traits/associated-types.md index 3330ce80993d9..1fffa3ff8f7ff 100644 --- a/src/doc/rustc-dev-guide/src/traits/associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/caching.md b/src/doc/rustc-dev-guide/src/traits/caching.md index f8453950959e6..7978306d199f6 100644 --- a/src/doc/rustc-dev-guide/src/traits/caching.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/hrtb.md b/src/doc/rustc-dev-guide/src/traits/hrtb.md index 7f77f274cd529..9986bbb1650e6 100644 --- a/src/doc/rustc-dev-guide/src/traits/hrtb.md +++ b/src/doc/rustc-dev-guide/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 4f32b55424044ceca54510e8d3102e0c6c9a7146 Mon Sep 17 00:00:00 2001 From: csmoe Date: Thu, 25 Oct 2018 11:01:08 +0800 Subject: [PATCH 0381/2516] replace bound region with placeholder --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- .../src/borrow_check/region_inference.md | 15 +++++++-------- src/doc/rustc-dev-guide/src/traits/hrtb.md | 14 +++++++------- 3 files changed, 15 insertions(+), 16 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 04d35777f83b3..82d6f9a21ae85 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 617133000e5f0..c754a5000e178 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/hrtb.md b/src/doc/rustc-dev-guide/src/traits/hrtb.md index 9986bbb1650e6..b562758819aa3 100644 --- a/src/doc/rustc-dev-guide/src/traits/hrtb.md +++ b/src/doc/rustc-dev-guide/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 8acc12f57cb52c20a053cbf31987fc717943a537 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 25 Oct 2018 11:33:30 +0800 Subject: [PATCH 0382/2516] Update src/borrow_check/region_inference.md Co-Authored-By: csmoe --- src/doc/rustc-dev-guide/src/borrow_check/region_inference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index c754a5000e178..0484b14d65b05 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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 730d1a60d61a8209118154d12c51f603dc43a08a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 25 Oct 2018 11:33:33 +0800 Subject: [PATCH 0383/2516] Update src/borrow_check/region_inference.md Co-Authored-By: csmoe --- src/doc/rustc-dev-guide/src/borrow_check/region_inference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 0484b14d65b05..95c2bc80444b7 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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 e82926334931c761894c7300a8b33cf698c96fbf Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 25 Oct 2018 11:33:38 +0800 Subject: [PATCH 0384/2516] Update src/traits/hrtb.md Co-Authored-By: csmoe --- src/doc/rustc-dev-guide/src/traits/hrtb.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/hrtb.md b/src/doc/rustc-dev-guide/src/traits/hrtb.md index b562758819aa3..8b3a9f649bd00 100644 --- a/src/doc/rustc-dev-guide/src/traits/hrtb.md +++ b/src/doc/rustc-dev-guide/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 57924519020ccd8a7acf299937d110308bee9485 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 25 Oct 2018 11:33:44 +0800 Subject: [PATCH 0385/2516] Update src/traits/caching.md Co-Authored-By: csmoe --- src/doc/rustc-dev-guide/src/traits/caching.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/caching.md b/src/doc/rustc-dev-guide/src/traits/caching.md index 7978306d199f6..c963aafc4a90b 100644 --- a/src/doc/rustc-dev-guide/src/traits/caching.md +++ b/src/doc/rustc-dev-guide/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 9e4ed397f23c304aaf6a0b93fb39ffcdeff708f8 Mon Sep 17 00:00:00 2001 From: Nikita Popov Date: Fri, 26 Oct 2018 14:34:09 +0200 Subject: [PATCH 0386/2516] Update TypeVariants to TyKind This has been renamed in https://github.com/rust-lang/rust/pull/53581. --- src/doc/rustc-dev-guide/src/ty.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 44017dd5b5f39..fea9afbeb0537 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 283b8a5da8c0b929d33ecc5487d037d8787533e3 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:15:11 -0500 Subject: [PATCH 0387/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 213a645aba490..9308b7d517df7 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 ebb6aff2f6890d9a80257d9233acf726f9b26f22 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:22:32 -0500 Subject: [PATCH 0388/2516] Reflect traits chapter structure in index key ideas --- src/doc/rustc-dev-guide/src/traits/index.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/index.md b/src/doc/rustc-dev-guide/src/traits/index.md index 053a26babb291..6a0e560a23fda 100644 --- a/src/doc/rustc-dev-guide/src/traits/index.md +++ b/src/doc/rustc-dev-guide/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 c81ea65b5b13bebe8ceeb2a0358fe745f0141004 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:22:57 -0500 Subject: [PATCH 0389/2516] Traits: Improve index layout, add chalk blurb --- src/doc/rustc-dev-guide/src/traits/index.md | 51 +++++++++++++-------- 1 file changed, 33 insertions(+), 18 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/index.md b/src/doc/rustc-dev-guide/src/traits/index.md index 6a0e560a23fda..2e3e6715c45ee 100644 --- a/src/doc/rustc-dev-guide/src/traits/index.md +++ b/src/doc/rustc-dev-guide/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 29b57a01c4b75b1f94708285b4ef94c35f2479c4 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:31:53 -0500 Subject: [PATCH 0390/2516] Associated types: Mention "lazy normalization" somewhere --- src/doc/rustc-dev-guide/src/traits/associated-types.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/associated-types.md b/src/doc/rustc-dev-guide/src/traits/associated-types.md index 1fffa3ff8f7ff..23da15228d1e6 100644 --- a/src/doc/rustc-dev-guide/src/traits/associated-types.md +++ b/src/doc/rustc-dev-guide/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 83cc11c679651565de01c968596dc3c6d0e5f8b1 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:32:04 -0500 Subject: [PATCH 0391/2516] Associated types: Break up text for readability --- .../src/traits/associated-types.md | 59 ++++++++++--------- 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/associated-types.md b/src/doc/rustc-dev-guide/src/traits/associated-types.md index 23da15228d1e6..d35fb71e171d0 100644 --- a/src/doc/rustc-dev-guide/src/traits/associated-types.md +++ b/src/doc/rustc-dev-guide/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 6c6caec5b3dc58f431eccc5b2269913a0421c17b Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:24:53 -0500 Subject: [PATCH 0392/2516] Add status of regions --- src/doc/rustc-dev-guide/src/traits/regions.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/regions.md b/src/doc/rustc-dev-guide/src/traits/regions.md index baa3582b639b8..4657529dc2bd7 100644 --- a/src/doc/rustc-dev-guide/src/traits/regions.md +++ b/src/doc/rustc-dev-guide/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 4073cf3d40edded85951463ca2aee513f70e6d8e Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:30:33 -0500 Subject: [PATCH 0393/2516] Get excited --- src/doc/rustc-dev-guide/src/traits/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/index.md b/src/doc/rustc-dev-guide/src/traits/index.md index 2e3e6715c45ee..84f812394bf8a 100644 --- a/src/doc/rustc-dev-guide/src/traits/index.md +++ b/src/doc/rustc-dev-guide/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 cfbb0a677eb2552e9a1a44fa9bd847d6e52d7b13 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Fri, 26 Oct 2018 13:42:14 -0500 Subject: [PATCH 0394/2516] Put "well-formedness checking" under "lowering rules" This was also intended to be a reference chapter, according to @scalexm. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 9308b7d517df7..efe963c3fcb04 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 c434cef02a08f83c693391b97ee90538232e029b Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Fri, 26 Oct 2018 12:16:25 -0600 Subject: [PATCH 0395/2516] 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/doc/rustc-dev-guide/src/tests/adding.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 1120315b9ebfc..580741ccfe9c6 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 c8ebbf006cea64261ae1316557fa1a27194b7b0e Mon Sep 17 00:00:00 2001 From: scalexm Date: Wed, 17 Oct 2018 20:15:19 +0200 Subject: [PATCH 0396/2516] Write well-formedness checking chapter --- src/doc/rustc-dev-guide/src/traits/wf.md | 268 ++++++++++++++++++++++- 1 file changed, 263 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md index c002b8cc17be5..cd0fb5564a361 100644 --- a/src/doc/rustc-dev-guide/src/traits/wf.md +++ b/src/doc/rustc-dev-guide/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 971eb713564a41ddc8f2d4e4ebe9b8e7a4201256 Mon Sep 17 00:00:00 2001 From: scalexm Date: Mon, 29 Oct 2018 15:54:37 +0100 Subject: [PATCH 0397/2516] Add some examples for impls --- src/doc/rustc-dev-guide/src/traits/wf.md | 213 ++++++++++++++++++++--- 1 file changed, 192 insertions(+), 21 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md index cd0fb5564a361..bd1188d87ad1e 100644 --- a/src/doc/rustc-dev-guide/src/traits/wf.md +++ b/src/doc/rustc-dev-guide/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 2269c91587c276bc1284189ec6286a5fe436135c Mon Sep 17 00:00:00 2001 From: scalexm Date: Mon, 29 Oct 2018 18:58:13 +0100 Subject: [PATCH 0398/2516] Fix code blocks --- src/doc/rustc-dev-guide/src/traits/wf.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md index bd1188d87ad1e..4cef9ec84ae6c 100644 --- a/src/doc/rustc-dev-guide/src/traits/wf.md +++ b/src/doc/rustc-dev-guide/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 aaf6b2e27d3edb062c53804d9b3739d8ecebc82a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 29 Oct 2018 22:20:26 +0100 Subject: [PATCH 0399/2516] Fix a few things Co-Authored-By: scalexm --- src/doc/rustc-dev-guide/src/traits/wf.md | 28 ++++++++++++++---------- 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md index 4cef9ec84ae6c..ec391924a487a 100644 --- a/src/doc/rustc-dev-guide/src/traits/wf.md +++ b/src/doc/rustc-dev-guide/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 3c53bbeb1ab27455eaa6ee32bc67d0232d1e9102 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Mon, 29 Oct 2018 21:59:17 -0500 Subject: [PATCH 0400/2516] Add section on chalk structure --- .../src/traits/chalk-overview.md | 65 +++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 3473a0764381d..029b1460ef955 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 66e0b6e8c3c206b5e235c2561df01be566abefe1 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Mon, 29 Oct 2018 22:19:58 -0500 Subject: [PATCH 0401/2516] Move Resources to bottom --- .../src/traits/chalk-overview.md | 34 ++++++++----------- 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 029b1460ef955..20a71ef87543c 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 67c488d208584653f1e9de29dcc181eda0063ebd Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Mon, 29 Oct 2018 22:22:14 -0500 Subject: [PATCH 0402/2516] 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/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 20a71ef87543c..4abe0ac025d94 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 48315fca7b553e1ea2004a213f90bccb4dfc5531 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Tue, 30 Oct 2018 21:06:07 +0100 Subject: [PATCH 0403/2516] Fix a few more things Co-Authored-By: scalexm --- src/doc/rustc-dev-guide/src/traits/wf.md | 59 +++++++++++++++++------- 1 file changed, 42 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md index ec391924a487a..8c4938d3362f0 100644 --- a/src/doc/rustc-dev-guide/src/traits/wf.md +++ b/src/doc/rustc-dev-guide/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 eb17d75ec7dd8cc4c41864566e13c4b7ccfd1052 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Mon, 29 Oct 2018 22:31:59 -0500 Subject: [PATCH 0404/2516] Chalk Overview: Update old content --- .../src/traits/chalk-overview.md | 99 +++++++++++-------- 1 file changed, 59 insertions(+), 40 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 4abe0ac025d94..5e0f147ca9acd 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 d47c6f7d56ef9ab7e9a14fe363b61ad2db64fda2 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Tue, 30 Oct 2018 17:20:29 -0500 Subject: [PATCH 0405/2516] Chalk Overview: Organize and sort links --- .../src/traits/chalk-overview.md | 67 +++++++++---------- 1 file changed, 32 insertions(+), 35 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 5e0f147ca9acd..1a6e72bec6bfe 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 86aea24c27b04dc0b98f867f6c188b6815bdd03f Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Tue, 30 Oct 2018 18:03:42 -0500 Subject: [PATCH 0406/2516] Chalk Overview: Fill in testing section --- .../src/traits/chalk-overview.md | 39 +++++++++++++++---- 1 file changed, 32 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 1a6e72bec6bfe..59572479d03cd 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 6ff0b470bc380300f101b5266e832d82b6e0845a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 31 Oct 2018 15:33:20 -0500 Subject: [PATCH 0407/2516] Missing link --- .../src/borrow_check/moves_and_initialization/move_paths.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index c9e22a81c4c81..8fd7b3f196f2c 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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 5c7a3cf289b9ecc50cfe0ec58fd1b92baf13877d Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 22 Oct 2018 12:37:13 -0500 Subject: [PATCH 0408/2516] Clarify why 'static is free --- src/doc/rustc-dev-guide/src/traits/canonicalization.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md index 62c4d9f7483de..ca81d6fd16677 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonicalization.md +++ b/src/doc/rustc-dev-guide/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 27febd39f48f7abb005f768d06310789e8716a60 Mon Sep 17 00:00:00 2001 From: scalexm Date: Fri, 2 Nov 2018 21:50:36 +0100 Subject: [PATCH 0409/2516] Fix nits --- src/doc/rustc-dev-guide/src/traits/wf.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md index 8c4938d3362f0..f0cb03caab246 100644 --- a/src/doc/rustc-dev-guide/src/traits/wf.md +++ b/src/doc/rustc-dev-guide/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 98456ee73ba7e2aa3c82d8427f3c801d09025578 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Fri, 2 Nov 2018 15:42:21 -0500 Subject: [PATCH 0410/2516] Copy chalk_engine README --- src/doc/rustc-dev-guide/src/traits/slg.md | 279 +++++++++++++++++++++- 1 file changed, 277 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/slg.md b/src/doc/rustc-dev-guide/src/traits/slg.md index 1dc56e14c7135..8e4e451c434a1 100644 --- a/src/doc/rustc-dev-guide/src/traits/slg.md +++ b/src/doc/rustc-dev-guide/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 6819cc84933d2cd6e20cf0763f96e3e74908d8ae Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Sun, 4 Nov 2018 09:38:56 -0600 Subject: [PATCH 0411/2516] SLG: Add intro --- src/doc/rustc-dev-guide/src/traits/slg.md | 38 +++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/traits/slg.md b/src/doc/rustc-dev-guide/src/traits/slg.md index 8e4e451c434a1..d151377c55f47 100644 --- a/src/doc/rustc-dev-guide/src/traits/slg.md +++ b/src/doc/rustc-dev-guide/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 b01cd5e3bf0034f418dd790f81967b1574fbf12f Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Sun, 4 Nov 2018 09:39:31 -0600 Subject: [PATCH 0412/2516] SLG: Replace heritage section with links to it elsewhere Maybe we want to include this in the bibliography or something, though. --- src/doc/rustc-dev-guide/src/traits/slg.md | 57 +++++------------------ 1 file changed, 12 insertions(+), 45 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/slg.md b/src/doc/rustc-dev-guide/src/traits/slg.md index d151377c55f47..812afd1ec35ca 100644 --- a/src/doc/rustc-dev-guide/src/traits/slg.md +++ b/src/doc/rustc-dev-guide/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 08e19e8c441df33abb98374057a142b22d26198d Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Tue, 6 Nov 2018 14:47:56 -0700 Subject: [PATCH 0413/2516] Document ignore-llvm-version This documents the ignore-llvm-version directive. --- src/doc/rustc-dev-guide/src/tests/adding.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 580741ccfe9c6..418287355fdbb 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 548e029276723e22e8b2fc9f32d3ffacb430ec8b Mon Sep 17 00:00:00 2001 From: kenta7777 Date: Tue, 6 Nov 2018 14:49:01 +0900 Subject: [PATCH 0414/2516] revised a jemalloc statement in how-to-build-and-run.md --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 62461d3efdbd0..863536a0611a2 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 f036b1116a91bd219cc175dc13d580dcadf14906 Mon Sep 17 00:00:00 2001 From: kenta7777 Date: Wed, 7 Nov 2018 08:58:21 +0900 Subject: [PATCH 0415/2516] removed jemalloc statements. --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 863536a0611a2..d89457257282b 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 ab12b0bdc439bc72d2f1f8e8205dd9e153f383e9 Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Thu, 8 Nov 2018 13:42:44 +0300 Subject: [PATCH 0416/2516] Rename trans to codegen --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index d89457257282b..89ad4719911cb 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 074465e82767ef8b49b7159d655e7e42343cae11 Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Thu, 8 Nov 2018 15:29:17 +0300 Subject: [PATCH 0417/2516] Remove reference to copyright comment We don't need them anymore --- src/doc/rustc-dev-guide/src/tests/adding.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 418287355fdbb..5b86748142a0d 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 82dec391027b03b9304170b2d4ed3cde44c1ea80 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 8 Nov 2018 20:29:45 -0600 Subject: [PATCH 0418/2516] minor improvements --- src/doc/rustc-dev-guide/src/borrow_check.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check.md b/src/doc/rustc-dev-guide/src/borrow_check.md index 40858b1b4acf3..b3eeaa38747bb 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check.md +++ b/src/doc/rustc-dev-guide/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 1c70ca12452fd5e42ff62b53d9ada58742ed6c3f Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 8 Nov 2018 20:38:14 -0600 Subject: [PATCH 0419/2516] add a few links to rustdocs --- .../src/borrow_check/region_inference.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 95c2bc80444b7..e35849ef6098a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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 cad4863365f0babe27d13a09c728737c6a02766b Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 8 Nov 2018 21:34:17 -0600 Subject: [PATCH 0420/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index e35849ef6098a..d08e06a80fd50 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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 5fc68b823011efb650621aaf1d7a88662c0de56d Mon Sep 17 00:00:00 2001 From: Gareth Ellis Date: Thu, 8 Nov 2018 19:55:46 -0800 Subject: [PATCH 0421/2516] Fixed Spelling Mistake In MIR/index.md - "alloated" --- src/doc/rustc-dev-guide/src/mir/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index d69606d66f466..baaf23c36974f 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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 d5682379bc36597176ec11c02df26d0db9663f7e Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Thu, 8 Nov 2018 16:46:39 +0300 Subject: [PATCH 0422/2516] document the interaction between macros and nameres "The name resolution is a separate pass" is a wishful thinking :( --- src/doc/rustc-dev-guide/src/name-resolution.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index bba3142fc08d7..3117217e5e35e 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 5595dbf2453fa2c40d0cbc893491416f15226fab Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Fri, 2 Nov 2018 12:43:36 +0100 Subject: [PATCH 0423/2516] Document MIR building somewhat --- .../rustc-dev-guide/src/mir/construction.md | 110 ++++++++++++++++++ 1 file changed, 110 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 898fcd529ed67..606301fdb8aa1 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 a820756e7b7344e317490c489eba355d549a3c2b Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Mon, 5 Nov 2018 07:37:14 +0100 Subject: [PATCH 0424/2516] Link to docs and address some review comments --- .../rustc-dev-guide/src/mir/construction.md | 26 ++++++++++++------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 606301fdb8aa1..d329da3c1393f 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 5ba2dd6d8f5ec1f5c8a4a949fc8c4a84341551ec Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Mon, 5 Nov 2018 07:39:18 +0100 Subject: [PATCH 0425/2516] Split overcomplicated sentence into two --- src/doc/rustc-dev-guide/src/mir/construction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index d329da3c1393f..a82a5e3a44f21 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 2a235197be99c9ba24e1da7f0e02ca8d911a4d6a Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 5 Nov 2018 07:46:24 +0100 Subject: [PATCH 0426/2516] Explain the unpack! macro --- .../rustc-dev-guide/src/mir/construction.md | 56 ++++++++++++++----- 1 file changed, 42 insertions(+), 14 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index a82a5e3a44f21..3e300d43dd958 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 4bc2711dd267251c752119f278eb71ab2f06f137 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Mon, 5 Nov 2018 07:52:09 +0100 Subject: [PATCH 0427/2516] Address most other review comments --- src/doc/rustc-dev-guide/src/mir/construction.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 3e300d43dd958..b7bd6bec6a02b 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 6b4d15869a9b386b703b2f836439b651afafa4e2 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Mon, 5 Nov 2018 12:59:19 +0100 Subject: [PATCH 0428/2516] Fix tidy --- src/doc/rustc-dev-guide/src/mir/construction.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index b7bd6bec6a02b..fec1df677acb2 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 9d37e01ac5ea6c5019d990a4f3b881170df492b8 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Nov 2018 18:58:29 +0100 Subject: [PATCH 0429/2516] Grammar nit Co-Authored-By: oli-obk --- src/doc/rustc-dev-guide/src/mir/construction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index fec1df677acb2..3c0fbd11a0a3a 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 b871e0466f40ffe533870110b87d564610cda94c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Nov 2018 19:01:59 +0100 Subject: [PATCH 0430/2516] caps nit Co-Authored-By: oli-obk --- src/doc/rustc-dev-guide/src/mir/construction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 3c0fbd11a0a3a..b22b67a3683b9 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 23b2ac55b8f42c4752f92f8c7efb8a70ba52edfb Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Nov 2018 19:02:14 +0100 Subject: [PATCH 0431/2516] english is hard Co-Authored-By: oli-obk --- src/doc/rustc-dev-guide/src/mir/construction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index b22b67a3683b9..4217a58a2e61b 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 959dd387bf8bab261ade10ebadb248e37765501a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Nov 2018 19:02:49 +0100 Subject: [PATCH 0432/2516] Missing connection between two consecutive sentences Co-Authored-By: oli-obk --- src/doc/rustc-dev-guide/src/mir/construction.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 4217a58a2e61b..5f54e21803d78 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 4084ee2544d114aca58a41b40abea4dc029d87f5 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Nov 2018 19:03:29 +0100 Subject: [PATCH 0433/2516] Clarify aggregates Co-Authored-By: oli-obk --- src/doc/rustc-dev-guide/src/mir/construction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 5f54e21803d78..d2ce1644994c8 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 fb421580f098ec252790ad23c467d38061e30929 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Thu, 8 Nov 2018 18:57:59 +0100 Subject: [PATCH 0434/2516] Remove a sentence from the end of a chapter because it also appears right at the start of the chapter --- src/doc/rustc-dev-guide/src/mir/construction.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index d2ce1644994c8..1e52730a2aa5a 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 dcb15af00489785aaf6ed6b2c04db168c5ba9860 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Thu, 8 Nov 2018 19:29:37 +0100 Subject: [PATCH 0435/2516] Line length checks --- src/doc/rustc-dev-guide/src/mir/construction.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 1e52730a2aa5a..314e0daa1fd4a 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 4b26ea4b5040f00e55829a7fe1115e452e860e98 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Fri, 9 Nov 2018 10:29:56 +0100 Subject: [PATCH 0436/2516] Don't try to build some example code snippets --- src/doc/rustc-dev-guide/src/mir/construction.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 314e0daa1fd4a..03e220cb459f5 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 ed24e55436f63b8ee01ab75ecf8b3d5bf34d2092 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 9 Nov 2018 19:31:47 -0600 Subject: [PATCH 0437/2516] Don't keep recompiling! --- src/doc/rustc-dev-guide/ci/install.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 80f8de4e8a513..947d751b488ee 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 8dbc5f6e310550fa49cbbbd336fecaa75c262c63 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 10 Nov 2018 22:06:15 -0600 Subject: [PATCH 0438/2516] start on walkthrough --- src/doc/rustc-dev-guide/src/walkthrough.md | 147 +++++++++++++++++++++ 1 file changed, 147 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index ab158177a420d..680f2b831bfd3 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 a57ea31fe246172351691d06db892d76f4a0ff4d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 10 Nov 2018 22:41:27 -0600 Subject: [PATCH 0439/2516] add a bit more --- src/doc/rustc-dev-guide/src/walkthrough.md | 67 +++++++++++++++++++++- 1 file changed, 66 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 680f2b831bfd3..738828bbeaa10 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 ca87e30f145d3a2916ff49437f2b9ae3e897f6d2 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 11 Nov 2018 16:32:11 -0600 Subject: [PATCH 0440/2516] add a bit more --- src/doc/rustc-dev-guide/src/walkthrough.md | 45 ++++++++++++++++------ 1 file changed, 34 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 738828bbeaa10..8cd511d926ae0 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 ad8c7442043b6827fb1688f17f42b5d718acc103 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 0441/2516] Fix typo (#238) "is is" ~> "it is" --- src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md index a0490adf351c8..e1a6c1361c8de 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md +++ b/src/doc/rustc-dev-guide/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 b2bac8c4b52de6b28473b7ee694e30608ce3fa86 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 19 Nov 2018 15:34:02 -0600 Subject: [PATCH 0442/2516] finish walkthrough --- src/doc/rustc-dev-guide/src/walkthrough.md | 31 +++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 8cd511d926ae0..4eae1397d9bba 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 f85362d60e8cb2e5f140953e2b1b42c6e20913bf Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Mon, 19 Nov 2018 18:28:10 -0600 Subject: [PATCH 0443/2516] SLG: Add links and mark-i-m's suggestions --- src/doc/rustc-dev-guide/src/traits/slg.md | 117 +++++++++++++--------- 1 file changed, 68 insertions(+), 49 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/slg.md b/src/doc/rustc-dev-guide/src/traits/slg.md index 812afd1ec35ca..dcddd01f581f0 100644 --- a/src/doc/rustc-dev-guide/src/traits/slg.md +++ b/src/doc/rustc-dev-guide/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 0a41b2ea1086d419f7ee9b497aba82a1e240f8d0 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 26 Nov 2018 11:06:41 -0600 Subject: [PATCH 0444/2516] add link to stabilization pr --- src/doc/rustc-dev-guide/src/walkthrough.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 4eae1397d9bba..e77a0f6906042 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 32a766cafe5a8decc42ceb1af4eafec7f96c7226 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 26 Nov 2018 11:13:21 -0600 Subject: [PATCH 0445/2516] make the line-length script respect 100 char limit XD (#240) :rofl: :rofl: :rofl: --- src/doc/rustc-dev-guide/ci/check_line_lengths.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh b/src/doc/rustc-dev-guide/ci/check_line_lengths.sh index 5b7b12d3e5ea9..32bf739e4dc24 100755 --- a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh +++ b/src/doc/rustc-dev-guide/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 dd16228a9a0b6f09845ab86edc4e1aa416e33350 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 26 Nov 2018 15:24:39 -0600 Subject: [PATCH 0446/2516] fix relative link (#242) --- src/doc/rustc-dev-guide/src/traits/lowering-module.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md index c9c4accc1c4e8..93948405113ff 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-module.md +++ b/src/doc/rustc-dev-guide/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 7752cbf3b2e9426bdf380e647970a959502eea86 Mon Sep 17 00:00:00 2001 From: Vadim Petrochenkov Date: Sun, 2 Dec 2018 01:10:43 +0400 Subject: [PATCH 0447/2516] 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 --- src/doc/rustc-dev-guide/.gitattributes | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 src/doc/rustc-dev-guide/.gitattributes diff --git a/src/doc/rustc-dev-guide/.gitattributes b/src/doc/rustc-dev-guide/.gitattributes new file mode 100644 index 0000000000000..d56abbf3047f0 --- /dev/null +++ b/src/doc/rustc-dev-guide/.gitattributes @@ -0,0 +1,2 @@ +# Set the default behavior, in case people don't have core.autocrlf set. +* text=auto eol=lf From 86bd005ff617d91cdfe320f204a5a306a8180034 Mon Sep 17 00:00:00 2001 From: yui-knk Date: Sat, 1 Dec 2018 22:11:05 +0900 Subject: [PATCH 0448/2516] Fix the file path where AST is defined --- src/doc/rustc-dev-guide/src/high-level-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 733c523c90e6f..93b5592c3a563 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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 1d99fdb8ef8a4da833a0825bb6d76dae7d1671c0 Mon Sep 17 00:00:00 2001 From: Andy Wortman Date: Sat, 1 Dec 2018 11:30:26 -0800 Subject: [PATCH 0449/2516] fix some linkrotted links --- src/doc/rustc-dev-guide/README.md | 2 +- src/doc/rustc-dev-guide/src/about-this-guide.md | 2 +- src/doc/rustc-dev-guide/src/diag.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 45c7503fec573..af23454ba4c9e 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 79106736ffdb8..56f0b7538a7f7 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 936420ab6ecb4..00bb23b4c94ab 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 802d3cc665f98f5367b67b6829e24e8466423055 Mon Sep 17 00:00:00 2001 From: Edd Barrett Date: Tue, 27 Nov 2018 13:31:38 +0000 Subject: [PATCH 0450/2516] Mention that tests need a Python-enabled gdb. --- src/doc/rustc-dev-guide/src/tests/running.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index f8889c8a4b393..ceabe3a69060f 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 c8aeda614656c0b8ee1132edf4f40d6c03599c29 Mon Sep 17 00:00:00 2001 From: Edd Barrett Date: Mon, 3 Dec 2018 15:46:55 +0000 Subject: [PATCH 0451/2516] Explain how to check if gdb supports Python. --- src/doc/rustc-dev-guide/src/tests/running.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index ceabe3a69060f..62f3ea4d7ea17 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 f51e93a653a5db71d2bbd9260dd6f40bfc467a9d Mon Sep 17 00:00:00 2001 From: Edd Barrett Date: Mon, 3 Dec 2018 17:27:14 +0000 Subject: [PATCH 0452/2516] Provide a Python example. --- src/doc/rustc-dev-guide/src/tests/running.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 62f3ea4d7ea17..1250fa77b7a90 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 284c0254b361adc1106b4d3ff4bc4a6c8271b5ad Mon Sep 17 00:00:00 2001 From: Avelino Date: Wed, 5 Dec 2018 18:12:35 -0200 Subject: [PATCH 0453/2516] fixed typo issues link --- src/doc/rustc-dev-guide/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index af23454ba4c9e..ba5b1cde40df3 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 82f6ee311ebe9fd4109ea45e22e899dc30c83c31 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Wed, 5 Dec 2018 07:38:34 -0800 Subject: [PATCH 0454/2516] Add some documentation about updating LLVM --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/codegen/updating-llvm.md | 149 ++++++++++++++++++ 2 files changed, 150 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/codegen/updating-llvm.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index efe963c3fcb04..bfb112ce64248 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen/updating-llvm.md b/src/doc/rustc-dev-guide/src/codegen/updating-llvm.md new file mode 100644 index 0000000000000..e29e041b2b7a7 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 8cbd00d6129f36b651a95030ac00fa7eefe11a8a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 11 Dec 2018 14:46:35 -0600 Subject: [PATCH 0455/2516] a few updates --- .../src/borrow_check/region_inference.md | 32 +++++++++++++------ 1 file changed, 23 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index d08e06a80fd50..762a844772730 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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 64d11de0d9fcb94f19c12e250f7f7239e506f52f Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 11 Dec 2018 15:22:17 -0600 Subject: [PATCH 0456/2516] added example, reworked inference section --- .../src/borrow_check/region_inference.md | 125 +++++++++++++----- 1 file changed, 93 insertions(+), 32 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 762a844772730..7fe50b870c71c 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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 5ea235e9665377e4db47a432065239e670ea4bac Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 11 Dec 2018 15:25:03 -0600 Subject: [PATCH 0457/2516] update a couple of links --- src/doc/rustc-dev-guide/src/compiler-team.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index a6328198ca5ed..728325687d2e0 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 136e62f1f757ddeccaf60b82b0e9d4ab8067aa1e Mon Sep 17 00:00:00 2001 From: Dan Robertson Date: Wed, 12 Dec 2018 02:08:40 +0000 Subject: [PATCH 0458/2516] Fix link to rustc_mir::hair::cx::expr --- src/doc/rustc-dev-guide/src/mir/construction.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 03e220cb459f5..f0e3cf76ad420 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 3826e3d027b20a5ed2c4d0a86b98ca202dff2b9f Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Fri, 14 Dec 2018 16:58:19 +0100 Subject: [PATCH 0459/2516] Add graphs that I forgot to push in the original PR --- .../rustc-dev-guide/src/mir/construction.md | 7 + .../rustc-dev-guide/src/mir/mir_detailed.dot | 27 ++ .../rustc-dev-guide/src/mir/mir_detailed.svg | 300 ++++++++++++++++++ .../rustc-dev-guide/src/mir/mir_overview.dot | 10 + .../rustc-dev-guide/src/mir/mir_overview.svg | 103 ++++++ 5 files changed, 447 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/mir/mir_detailed.dot create mode 100644 src/doc/rustc-dev-guide/src/mir/mir_detailed.svg create mode 100644 src/doc/rustc-dev-guide/src/mir/mir_overview.dot create mode 100644 src/doc/rustc-dev-guide/src/mir/mir_overview.svg diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index f0e3cf76ad420..0e0bf35e7392d 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/mir_detailed.dot b/src/doc/rustc-dev-guide/src/mir/mir_detailed.dot new file mode 100644 index 0000000000000..1494f4f0bd2a3 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/mir_detailed.svg b/src/doc/rustc-dev-guide/src/mir/mir_detailed.svg new file mode 100644 index 0000000000000..771e9e5dc0a79 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/mir_overview.dot b/src/doc/rustc-dev-guide/src/mir/mir_overview.dot new file mode 100644 index 0000000000000..c0b51674dc178 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/mir_overview.svg b/src/doc/rustc-dev-guide/src/mir/mir_overview.svg new file mode 100644 index 0000000000000..b8f092cd28019 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 088fa3aaf81c71d7e65a6ec434d8e6e0e2b1bde9 Mon Sep 17 00:00:00 2001 From: Roberto Vidal Date: Fri, 14 Dec 2018 10:11:27 +0100 Subject: [PATCH 0460/2516] Fixes broken links --- src/doc/rustc-dev-guide/src/diag.md | 2 +- src/doc/rustc-dev-guide/src/hir.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 00bb23b4c94ab..9a80203146fdb 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index e6bca7f37d029..34e478ee4d0a1 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 34eac7f478d509d91dac608a401af5b210efc734 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 23 Dec 2018 10:11:26 -0600 Subject: [PATCH 0461/2516] Fix link --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index e1bde6863a307..546e9f9b78de3 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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 75c3d9b919248dfa9627ecf966cc795c5dc4daec Mon Sep 17 00:00:00 2001 From: ednix Date: Sat, 22 Dec 2018 23:49:31 +0530 Subject: [PATCH 0462/2516] 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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 89ad4719911cb..cc1a5f9c09c40 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 a65fb787186abc01bc0fa7532c0f6fdb9142042f Mon Sep 17 00:00:00 2001 From: ednix Date: Sat, 22 Dec 2018 23:54:05 +0530 Subject: [PATCH 0463/2516] Do what the last commit said it did --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index cc1a5f9c09c40..077ea39f91c20 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 3d46aae7dd8578618aa2dcaf4118381c9c838d80 Mon Sep 17 00:00:00 2001 From: ednix Date: Sun, 23 Dec 2018 13:18:56 +0530 Subject: [PATCH 0464/2516] Fix formatting, follow 100 char line length limit No idea why the Markdown stuff got dropped last time. Hopefully everything is fine now. --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 077ea39f91c20..241852b19daab 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 250741242e8c6baec595bf72af1eea9fa0a39843 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 1 Jan 2019 11:26:10 +0100 Subject: [PATCH 0465/2516] 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/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 82d6f9a21ae85..0e697aeea73dd 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 111684cc7e70d93c4d28802fb45b1ba11f0560bb Mon Sep 17 00:00:00 2001 From: Igor Matuszewski Date: Fri, 4 Jan 2019 15:23:15 +0100 Subject: [PATCH 0466/2516] Mention old incr. comp. design doc --- src/doc/rustc-dev-guide/src/incremental-compilation.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/incremental-compilation.md b/src/doc/rustc-dev-guide/src/incremental-compilation.md index 0a25e16648a95..bed21f115cb57 100644 --- a/src/doc/rustc-dev-guide/src/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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 93f5fc52c3852636154ecc1835c384b5fe54a028 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Tue, 15 Jan 2019 17:07:06 -0500 Subject: [PATCH 0467/2516] issue_130_stabilization_guide --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/stabilization_guide.md | 181 ++++++++++++++++++ 2 files changed, 182 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/stabilization_guide.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index bfb112ce64248..9bdf892785c8a 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md new file mode 100644 index 0000000000000..af86b450eaa2f --- /dev/null +++ b/src/doc/rustc-dev-guide/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 a09d916d14fe5628d2d8496d31866bbda7cee2cc Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:00:36 -0500 Subject: [PATCH 0468/2516] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index af86b450eaa2f..db8b5c3f4d5a4 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 144826b2502f2e8e2ca4ed687e74789345b00f02 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:02:20 -0500 Subject: [PATCH 0469/2516] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index db8b5c3f4d5a4..22ec49f8ada99 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 008735c00abfa49ddbe95c90ce18880041c22f7f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:02:36 -0500 Subject: [PATCH 0470/2516] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 22ec49f8ada99..3af4aff738f48 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 5ffa85846761bb338643ab488c8a9accf7884101 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:02:51 -0500 Subject: [PATCH 0471/2516] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 3af4aff738f48..d21fbb1747afb 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 76621facb83e3c5a3f4c03a731a3de53dc4e1082 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:03:13 -0500 Subject: [PATCH 0472/2516] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index d21fbb1747afb..a245d170b3397 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 5619e6482cf785f1f2cc801dc48077699962fa92 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:10:56 -0500 Subject: [PATCH 0473/2516] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index a245d170b3397..d73e96d8c3a1b 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 cf3b8dcae9c6791f8964715152e8e2bb8eb85bee Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Tue, 15 Jan 2019 22:22:36 -0500 Subject: [PATCH 0474/2516] issue_180 incorporated the review comments --- .../src/stabilization_guide.md | 157 +++++++++--------- 1 file changed, 74 insertions(+), 83 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index d73e96d8c3a1b..2974f6314e40e 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 499458d765e6e87afa92531613a820403c10dcce Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 17 Jan 2019 14:04:50 -0500 Subject: [PATCH 0475/2516] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 2974f6314e40e..a17eff1628e86 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 e750b37068deb7727074f34ea1934b8e088b9fcb Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 17 Jan 2019 14:05:13 -0500 Subject: [PATCH 0476/2516] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index a17eff1628e86..89407308d270f 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 c86ce3d044f5140bfefe5b3c53b37d3ac9adcd32 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 17 Jan 2019 14:09:41 -0500 Subject: [PATCH 0477/2516] issue 130 stabilization guide --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 89407308d270f..e56313bb0cb36 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 8beadbb9fc0f80e16c67b82f4bf6bc0bd9bda18f Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 17 Jan 2019 14:20:24 -0500 Subject: [PATCH 0478/2516] issue 130 stabilization guide --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 5 ++++- src/doc/rustc-dev-guide/src/walkthrough.md | 4 ---- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index e56313bb0cb36..7f3c7321a80ec 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index e77a0f6906042..fa259de991c2b 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 1fca3dac68802368ac8848664f663a64295a6fe8 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 17 Jan 2019 16:40:07 -0500 Subject: [PATCH 0479/2516] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 7f3c7321a80ec..c217c2251a7c9 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 2e169e078ccc36204a25d9250173983ef5ac7e58 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 17 Jan 2019 16:40:18 -0500 Subject: [PATCH 0480/2516] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index c217c2251a7c9..6296aaa0118c9 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 f2426a11e25b233bb7db7a1ae674dcc278a55bc5 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 17 Jan 2019 17:04:03 -0500 Subject: [PATCH 0481/2516] issue 130 stabilization guide --- .../src/stabilization_guide.md | 29 ++++++++++--------- src/doc/rustc-dev-guide/src/walkthrough.md | 4 +-- 2 files changed, 16 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 6296aaa0118c9..eb2c642989b50 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index fa259de991c2b..2823426be1008 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 56c8f82ba3c51e3dea4a1422d06123b3f8eaca9e Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 17 Jan 2019 18:57:05 -0600 Subject: [PATCH 0482/2516] Update stabilization_guide.md --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index eb2c642989b50..ab5340c95dc99 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 d25c158768628cda39607e7c49c00675d8b4657e Mon Sep 17 00:00:00 2001 From: king6cong Date: Fri, 18 Jan 2019 00:06:00 +0800 Subject: [PATCH 0483/2516] Update the doc related to complier logging --- .../rustc-dev-guide/src/compiler-debugging.md | 59 +++++-------------- 1 file changed, 15 insertions(+), 44 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index aca7f7424b8c9..19c939d6db228 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 1d43ad5604e7e0b05ae22cc20eaaaf2f6fba31e9 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 18 Jan 2019 14:09:30 -0600 Subject: [PATCH 0484/2516] Fix relative link --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 0e697aeea73dd..af099d09a6bc8 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 e709d9bfcc008ea89d7a8963b335ebc6dde90291 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 18 Jan 2019 14:36:52 -0600 Subject: [PATCH 0485/2516] Typo + minor edits --- src/doc/rustc-dev-guide/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index ba5b1cde40df3..e6230439e9179 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 a0badea0c7ecddb45d5b5c93607f46689100dad5 Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 18 Jan 2019 15:16:13 -0600 Subject: [PATCH 0486/2516] Reorganize the book into 3 parts --- src/doc/rustc-dev-guide/src/SUMMARY.md | 27 ++++++++++++------- .../rustc-dev-guide/src/about-this-guide.md | 5 ++++ src/doc/rustc-dev-guide/src/part-1-intro.md | 7 +++++ src/doc/rustc-dev-guide/src/part-2-intro.md | 12 +++++++++ 4 files changed, 41 insertions(+), 10 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/part-1-intro.md create mode 100644 src/doc/rustc-dev-guide/src/part-2-intro.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 9bdf892785c8a..a17a3c6a0898d 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 56f0b7538a7f7..30a3b88708f0b 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-1-intro.md b/src/doc/rustc-dev-guide/src/part-1-intro.md new file mode 100644 index 0000000000000..c829f8c3bd3b4 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-2-intro.md b/src/doc/rustc-dev-guide/src/part-2-intro.md new file mode 100644 index 0000000000000..6dd26f44cc126 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 ca0fc8ec8ffe967d472018227b1d092c5e94c6fe Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 18 Jan 2019 15:32:17 -0600 Subject: [PATCH 0487/2516] better titles a la Niko --- src/doc/rustc-dev-guide/src/SUMMARY.md | 4 ++-- src/doc/rustc-dev-guide/src/part-1-intro.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index a17a3c6a0898d..4df03dc7aec21 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-1-intro.md b/src/doc/rustc-dev-guide/src/part-1-intro.md index c829f8c3bd3b4..65cb1ae482d09 100644 --- a/src/doc/rustc-dev-guide/src/part-1-intro.md +++ b/src/doc/rustc-dev-guide/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 917c7b5149561be728cdb3a1ed461e1c658854e1 Mon Sep 17 00:00:00 2001 From: rchaser53 Date: Sat, 19 Jan 2019 23:48:13 +0900 Subject: [PATCH 0488/2516] fix related miri variables rename variables like below - Value => ConstValue - PrimVal => Scalar - Value::ByVal => ConstValue::Scalar - Value::ByValPair => ConstValue::ScalarPair --- src/doc/rustc-dev-guide/src/const-eval.md | 6 +++--- src/doc/rustc-dev-guide/src/miri.md | 16 ++++++++-------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/const-eval.md b/src/doc/rustc-dev-guide/src/const-eval.md index 1f801fb22b10d..aaa2ed2d6cc97 100644 --- a/src/doc/rustc-dev-guide/src/const-eval.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index a3c7b3ff4a2bc..cbed690eb8740 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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 ca84da549237f6eaea47fc25aa2b0d4a5f4ae91e Mon Sep 17 00:00:00 2001 From: rchaser53 Date: Tue, 22 Jan 2019 00:24:36 +0900 Subject: [PATCH 0489/2516] fix unwrap_u64 and to_raw_bits --- src/doc/rustc-dev-guide/src/miri.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index cbed690eb8740..d361103f20fba 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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 b750802ba1383b4d14afde94b67168807a7f35ab Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Mon, 21 Jan 2019 16:45:09 +0100 Subject: [PATCH 0490/2516] Fix TokenStream link --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 546e9f9b78de3..e1bde6863a307 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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 f04a5262c94363c33527d0195b29aaae91a9bb72 Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Tue, 22 Jan 2019 15:26:01 +0100 Subject: [PATCH 0491/2516] Add "The Query Evaluation Model in Detail" Chapter. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../query-evaluation-model-in-detail.md | 236 ++++++++++++++++++ src/doc/rustc-dev-guide/src/query.md | 60 +---- 3 files changed, 243 insertions(+), 54 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 9bdf892785c8a..4d61367023173 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md new file mode 100644 index 0000000000000..d2dc104793eea --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index a0c0d6282916e..ee7d60e4b0883 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 1f77162df7ec75dcd307f5f90062ae843ded1ca9 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 12:41:18 -0600 Subject: [PATCH 0492/2516] update text about copyright headers --- src/doc/rustc-dev-guide/src/conventions.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index d392ebd572220..385658dac5c3d 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 320a645f3a99ca7486ba7df936abc0c42c155792 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 12:56:40 -0600 Subject: [PATCH 0493/2516] update conventions --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/conventions.md | 17 +++++++++++++++- src/doc/rustc-dev-guide/src/crates-io.md | 23 ++++++++++++++++++++++ 3 files changed, 40 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/src/crates-io.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 4df03dc7aec21..f472bfaabb561 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 385658dac5c3d..d9f462a053739 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/crates-io.md b/src/doc/rustc-dev-guide/src/crates-io.md new file mode 100644 index 0000000000000..21dd00afe5077 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 508f794f291931f03165647de5c25c667087078a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 21:55:52 -0600 Subject: [PATCH 0494/2516] fix #182 --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index e1bde6863a307..c0a1d03a9f32e 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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 1ffc443a8aaabbf0fed3dfcf946d642e3dec5602 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 13:15:12 -0600 Subject: [PATCH 0495/2516] add link to sunjay talk --- src/doc/rustc-dev-guide/src/traits/specialization.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/traits/specialization.md b/src/doc/rustc-dev-guide/src/traits/specialization.md index 671e5e01682f5..13edceca14201 100644 --- a/src/doc/rustc-dev-guide/src/traits/specialization.md +++ b/src/doc/rustc-dev-guide/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 60e5886f82b40a2e8e315c7ccb5d719ee0dfa482 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 19:31:49 -0600 Subject: [PATCH 0496/2516] add comments from sunjay --- src/doc/rustc-dev-guide/src/traits/specialization.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/specialization.md b/src/doc/rustc-dev-guide/src/traits/specialization.md index 13edceca14201..7a30314b4b459 100644 --- a/src/doc/rustc-dev-guide/src/traits/specialization.md +++ b/src/doc/rustc-dev-guide/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 49fb0c34d921eb7705dbdecd33cbf8c0e63102d5 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 Jan 2019 15:02:36 -0600 Subject: [PATCH 0497/2516] fix updating-docs link, add regression test --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/important-links.md | 12 ++++++++++++ src/doc/rustc-dev-guide/src/stabilization_guide.md | 2 ++ 3 files changed, 15 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/important-links.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 4df03dc7aec21..2d8c170241570 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/important-links.md b/src/doc/rustc-dev-guide/src/important-links.md new file mode 100644 index 0000000000000..2dc759bf63c1a --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index ab5340c95dc99..56da5cdaf1667 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 decb484347cf0cf3d93d6173b88d2195d6881426 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Tue, 22 Jan 2019 16:00:24 -0600 Subject: [PATCH 0498/2516] Typo Co-Authored-By: mark-i-m --- src/doc/rustc-dev-guide/src/important-links.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/important-links.md b/src/doc/rustc-dev-guide/src/important-links.md index 2dc759bf63c1a..480be1bdbe086 100644 --- a/src/doc/rustc-dev-guide/src/important-links.md +++ b/src/doc/rustc-dev-guide/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 be2bd279e7d24bf2f5a41e300d81bace60c82872 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 Jan 2019 16:02:53 -0600 Subject: [PATCH 0499/2516] better grouping, more links --- src/doc/rustc-dev-guide/src/important-links.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/important-links.md b/src/doc/rustc-dev-guide/src/important-links.md index 480be1bdbe086..367532519c5e9 100644 --- a/src/doc/rustc-dev-guide/src/important-links.md +++ b/src/doc/rustc-dev-guide/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 f6127541d505e855f96be9f218555f6d3d5cf087 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 29 Jan 2019 10:55:57 -0600 Subject: [PATCH 0500/2516] add blurb about downloading artifacts; fix #77x --- .../rustc-dev-guide/src/compiler-debugging.md | 21 ++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 19c939d6db228..31f22105748e2 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 79c54b2e648ce2fb980f952c2e33c62fbc25198c Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Fri, 25 Jan 2019 16:50:22 +0100 Subject: [PATCH 0501/2516] Add a more detailed description of how incremental compilation works. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 5 +- .../rustc-dev-guide/src/appendix/glossary.md | 2 +- .../incremental-compilation-in-detail.md | 354 ++++++++++++++++++ .../{ => queries}/incremental-compilation.md | 0 .../query-evaluation-model-in-detail.md | 27 +- src/doc/rustc-dev-guide/src/query.md | 5 +- src/doc/rustc-dev-guide/src/variance.md | 2 +- 7 files changed, 376 insertions(+), 19 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md rename src/doc/rustc-dev-guide/src/{ => queries}/incremental-compilation.md (100%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 4d61367023173..cd3c9d3319db8 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 0e697aeea73dd..decfb44267e34 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md new file mode 100644 index 0000000000000..fbe226e90c0f6 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/incremental-compilation.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md similarity index 100% rename from src/doc/rustc-dev-guide/src/incremental-compilation.md rename to src/doc/rustc-dev-guide/src/queries/incremental-compilation.md diff --git a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index d2dc104793eea..41789637dddb3 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index ee7d60e4b0883..703c560e0c218 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md index 9fe98b4a149ee..c6a1a320bbfd8 100644 --- a/src/doc/rustc-dev-guide/src/variance.md +++ b/src/doc/rustc-dev-guide/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 63f2eb3186d3197b236ad752a7f828fe293a86e6 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Tue, 5 Feb 2019 22:46:53 -0800 Subject: [PATCH 0502/2516] `_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/doc/rustc-dev-guide/src/diag.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index 9a80203146fdb..cfdd82aa2a9e3 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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 db2316388c147aaac2764541d531f0f0fa8cf6a6 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 13:56:40 +0000 Subject: [PATCH 0503/2516] Add "lang item" to glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index a350080534403..a2effc7fcd92e 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 aa7359239842ef59dd200be4719898f19575c1ea Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 13:59:59 +0000 Subject: [PATCH 0504/2516] Add "item" to glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index a2effc7fcd92e..3ceef9344a692 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 6227b16f0baaa092699da90e58517e67adb3d423 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 14:03:39 +0000 Subject: [PATCH 0505/2516] Add "early-bound lifetime" and "late-bound lifetime" to the glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 3ceef9344a692..3b4df535de9b7 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 1c9c660f5549076a1cbf6ad5ab8af96d961f4416 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 14:09:49 +0000 Subject: [PATCH 0506/2516] Add "intern" to the glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 3b4df535de9b7..32171a374b271 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 02260c1b7cc3352f0765c47d598bb415a0556151 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 14:11:56 +0000 Subject: [PATCH 0507/2516] Add "memoise" to the glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 32171a374b271..3f10d731debcf 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 40623feedc0f7a970e1619e7af4ad0d8b540ae73 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 14:15:41 +0000 Subject: [PATCH 0508/2516] Add "drop glue" to the glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 3f10d731debcf..86a128efb1d4d 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 6422d38a06712e2d6f4dec29506f213143bda068 Mon Sep 17 00:00:00 2001 From: varkor Date: Thu, 5 Apr 2018 11:49:38 +0100 Subject: [PATCH 0509/2516] Add preliminary chapter on kinds --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/kinds.md | 31 ++++++++++++++++++++++++++ src/doc/rustc-dev-guide/src/ty.md | 6 +++-- 3 files changed, 36 insertions(+), 2 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/kinds.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 091860e9ab520..b27114f1e43e5 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/kinds.md b/src/doc/rustc-dev-guide/src/kinds.md new file mode 100644 index 0000000000000..d811423a8d1df --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index fea9afbeb0537..d9979bc0b4dc0 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 9523b06c6853f1a9b6cb8eac406450217df85916 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 14:38:15 +0000 Subject: [PATCH 0510/2516] Add more information and an example to Kind chapter --- src/doc/rustc-dev-guide/src/kinds.md | 62 ++++++++++++++++++---------- 1 file changed, 40 insertions(+), 22 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/kinds.md b/src/doc/rustc-dev-guide/src/kinds.md index d811423a8d1df..bd483c86837b6 100644 --- a/src/doc/rustc-dev-guide/src/kinds.md +++ b/src/doc/rustc-dev-guide/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 ad3659cd58d9f6196fb4a0acef6bed480099b7da Mon Sep 17 00:00:00 2001 From: varkor Date: Mon, 18 Feb 2019 22:57:57 +0000 Subject: [PATCH 0511/2516] Ignore Rust snippet --- src/doc/rustc-dev-guide/src/kinds.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/kinds.md b/src/doc/rustc-dev-guide/src/kinds.md index bd483c86837b6..d5e218c31942c 100644 --- a/src/doc/rustc-dev-guide/src/kinds.md +++ b/src/doc/rustc-dev-guide/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 21d7752e21b3a0e7b6e345660b456584ae5afe19 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Tue, 19 Feb 2019 00:15:07 +0000 Subject: [PATCH 0512/2516] Small clarifications to glossary definitions --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 86a128efb1d4d..a5d5bf56aa684 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 f81f087ec459100277f43dcdc5adb00c82f6970b Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 7 Feb 2019 22:45:01 -0500 Subject: [PATCH 0513/2516] issue_130_7 implementing new features --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/implementing_new_feature.md | 135 ++++++++++++++++++ 2 files changed, 136 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/implementing_new_feature.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index b27114f1e43e5..723608da936cd 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_feature.md b/src/doc/rustc-dev-guide/src/implementing_new_feature.md new file mode 100644 index 0000000000000..2bc65e145d661 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 2e90be41191918c59278448d123f43dee01eec8c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 12:55:34 -0500 Subject: [PATCH 0514/2516] Update src/SUMMARY.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 723608da936cd..0761e734de794 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 9bca4aa39b39cddfa829fce08131fb0b12bf6a7a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 12:57:01 -0500 Subject: [PATCH 0515/2516] Update src/implementing_new_feature.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/implementing_new_feature.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_feature.md b/src/doc/rustc-dev-guide/src/implementing_new_feature.md index 2bc65e145d661..d787954da346d 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_feature.md +++ b/src/doc/rustc-dev-guide/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 ef2e724354af9ba04fabcaad2b3a822e0eb85f64 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 12:57:26 -0500 Subject: [PATCH 0516/2516] Update src/implementing_new_feature.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/implementing_new_feature.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_feature.md b/src/doc/rustc-dev-guide/src/implementing_new_feature.md index d787954da346d..20c250527bc12 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_feature.md +++ b/src/doc/rustc-dev-guide/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 81d0e42cd318793f85560dd9e8159c18535f6071 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 12:58:01 -0500 Subject: [PATCH 0517/2516] Update src/implementing_new_feature.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/implementing_new_feature.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_feature.md b/src/doc/rustc-dev-guide/src/implementing_new_feature.md index 20c250527bc12..2344ab6f93221 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_feature.md +++ b/src/doc/rustc-dev-guide/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 2125621c69607cf13bcf17877098a648b97e566f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 12:58:38 -0500 Subject: [PATCH 0518/2516] Update src/implementing_new_feature.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/implementing_new_feature.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_feature.md b/src/doc/rustc-dev-guide/src/implementing_new_feature.md index 2344ab6f93221..ff26b85506a21 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_feature.md +++ b/src/doc/rustc-dev-guide/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 d159daf3c57daf2d7c33c36a032d059aa49b3cd1 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Wed, 20 Feb 2019 15:04:32 -0500 Subject: [PATCH 0519/2516] issue_130_7 updated with review comments --- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_feature.md create mode 100644 src/doc/rustc-dev-guide/src/implementing_new_features.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 0761e734de794..3ce74a4e5b482 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_feature.md b/src/doc/rustc-dev-guide/src/implementing_new_feature.md deleted file mode 100644 index ff26b85506a21..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md new file mode 100644 index 0000000000000..f1d501ce24b94 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 b7334e9586213e6f63631de6fe382140a1f1a88e Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 18:02:35 -0500 Subject: [PATCH 0520/2516] Update src/implementing_new_features.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/implementing_new_features.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index f1d501ce24b94..975d10ef84237 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 03b2339742f395454c4db838628cbcb2164b77fa Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 18:02:51 -0500 Subject: [PATCH 0521/2516] Update src/implementing_new_features.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/implementing_new_features.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 975d10ef84237..44c1ce510fc2c 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 c65854cf3ddbded37ea6230063c098bf85591858 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 18:03:01 -0500 Subject: [PATCH 0522/2516] Update src/implementing_new_features.md Co-Authored-By: rajcspsg --- src/doc/rustc-dev-guide/src/implementing_new_features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 44c1ce510fc2c..650d9915ce812 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 aa39490700ad4a0c3f6b339402419a755fb5f5f7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 12:35:21 -0600 Subject: [PATCH 0523/2516] Organize and finish debugging chapters --- src/doc/rustc-dev-guide/src/SUMMARY.md | 3 + .../rustc-dev-guide/src/codegen/debugging.md | 122 +++++++++++++ .../rustc-dev-guide/src/compiler-debugging.md | 161 +++--------------- src/doc/rustc-dev-guide/src/hir-debugging.md | 8 + src/doc/rustc-dev-guide/src/mir/debugging.md | 81 +++++++++ src/doc/rustc-dev-guide/src/mir/passes.md | 76 --------- 6 files changed, 241 insertions(+), 210 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/codegen/debugging.md create mode 100644 src/doc/rustc-dev-guide/src/hir-debugging.md create mode 100644 src/doc/rustc-dev-guide/src/mir/debugging.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 3ce74a4e5b482..dc2f46bd9c3de 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen/debugging.md b/src/doc/rustc-dev-guide/src/codegen/debugging.md new file mode 100644 index 0000000000000..acf917bd0e097 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 31f22105748e2..714385ca0515b 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir-debugging.md b/src/doc/rustc-dev-guide/src/hir-debugging.md new file mode 100644 index 0000000000000..bb7f541fd690f --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/debugging.md b/src/doc/rustc-dev-guide/src/mir/debugging.md new file mode 100644 index 0000000000000..93a79076c3074 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/passes.md b/src/doc/rustc-dev-guide/src/mir/passes.md index 7dc1249a0f574..a0de3ae0e4aa4 100644 --- a/src/doc/rustc-dev-guide/src/mir/passes.md +++ b/src/doc/rustc-dev-guide/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 358231e2d6bbd57a94a30d031afe0f61f7a827cc Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 12:59:34 -0600 Subject: [PATCH 0524/2516] fix link --- src/doc/rustc-dev-guide/src/codegen/debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/codegen/debugging.md b/src/doc/rustc-dev-guide/src/codegen/debugging.md index acf917bd0e097..51d5a3b2c35f9 100644 --- a/src/doc/rustc-dev-guide/src/codegen/debugging.md +++ b/src/doc/rustc-dev-guide/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 3fc2b4a379a84904760883ef7aa4a93914d7bf67 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 1 Mar 2019 17:02:54 -0600 Subject: [PATCH 0525/2516] update mdbook --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 947d751b488ee..835f231925157 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 1133c845f0538ed2e230ab6967370ee3995428f9 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 15 Mar 2019 17:24:46 -0500 Subject: [PATCH 0526/2516] chalk has moved to rust-lang --- .../src/traits/chalk-overview.md | 64 +++++++++---------- src/doc/rustc-dev-guide/src/traits/slg.md | 8 +-- 2 files changed, 36 insertions(+), 36 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 59572479d03cd..54046b22e400f 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/slg.md b/src/doc/rustc-dev-guide/src/traits/slg.md index dcddd01f581f0..98547575dc9ce 100644 --- a/src/doc/rustc-dev-guide/src/traits/slg.md +++ b/src/doc/rustc-dev-guide/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 112a21eacd0ed74d2b655345c9e19817e4ef410e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 15 Mar 2019 17:25:12 -0500 Subject: [PATCH 0527/2516] update rustc driver chapters --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- .../src/appendix/code-index.md | 7 ++- .../src/appendix/stupid-stats.md | 16 ++--- src/doc/rustc-dev-guide/src/rustc-driver.md | 63 ++++++------------- 4 files changed, 32 insertions(+), 56 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 6cd75c58888ca..d3cef1a25498b 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index c0a1d03a9f32e..3c71d6bbaa641 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md index a36cac42ba51c..5066973a93140 100644 --- a/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 39794983674d8..92754f6754fa8 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 e1bcaab5916cd77fa3d2fd13665c0442f2c5a13c Mon Sep 17 00:00:00 2001 From: varkor Date: Thu, 14 Mar 2019 13:17:20 +0000 Subject: [PATCH 0528/2516] Fix mask -> tag terminology --- src/doc/rustc-dev-guide/src/kinds.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/kinds.md b/src/doc/rustc-dev-guide/src/kinds.md index d5e218c31942c..ac6a2d35b57d7 100644 --- a/src/doc/rustc-dev-guide/src/kinds.md +++ b/src/doc/rustc-dev-guide/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 3da584e32b5d2e7252810d97e90599150f5a2cda Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 12 Mar 2019 13:54:50 -0300 Subject: [PATCH 0529/2516] Add experts map section to compiler team page --- src/doc/rustc-dev-guide/src/compiler-team.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index 728325687d2e0..b837c038ccb80 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 cf9a8c6f602fd42bcc9715818c628cc20d578152 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 19 Mar 2019 19:02:59 -0500 Subject: [PATCH 0530/2516] address Zoxc's comments --- src/doc/rustc-dev-guide/src/appendix/stupid-stats.md | 5 ++++- src/doc/rustc-dev-guide/src/rustc-driver.md | 8 ++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md index 5066973a93140..6ed7d1cbd9662 100644 --- a/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 92754f6754fa8..715e6295d4d49 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 51c36400abc68fb6fa8d80a434230bd0a2f7f8b5 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Thu, 21 Mar 2019 23:29:17 +0000 Subject: [PATCH 0531/2516] Small fix to code for checking feature gate --- src/doc/rustc-dev-guide/src/implementing_new_features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 650d9915ce812..8105e1474a611 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 5a9da9eba0c67ac0c2d5e3a43daae38b7877893f Mon Sep 17 00:00:00 2001 From: Dan Robertson Date: Wed, 20 Mar 2019 14:03:54 +0000 Subject: [PATCH 0532/2516] Update link to debugging codegen --- src/doc/rustc-dev-guide/src/codegen.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/codegen.md b/src/doc/rustc-dev-guide/src/codegen.md index 766dfff59d8c9..c8d51f31843eb 100644 --- a/src/doc/rustc-dev-guide/src/codegen.md +++ b/src/doc/rustc-dev-guide/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 c1c0a4ef507ba477b5cbb4154acec48b76a9b93e Mon Sep 17 00:00:00 2001 From: Denys Zariaiev Date: Sat, 16 Mar 2019 23:33:43 +0100 Subject: [PATCH 0533/2516] Add a note about `assembly` test suite. --- src/doc/rustc-dev-guide/src/tests/intro.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 4d509f3a8ed98..c043da42967c2 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 d3eb9dc1b63ccd9efcf1d9f35f9a6222f354ecdb Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 19 Mar 2019 18:50:01 -0500 Subject: [PATCH 0534/2516] Use eddyb's suggestion from #11 about logging --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 714385ca0515b..6747fd31cbccf 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 9cfa13ef0b80a90645979ff03487d02b95f4d2e0 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 23 Mar 2019 18:12:37 -0500 Subject: [PATCH 0535/2516] oops --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 6747fd31cbccf..bce5959dcf96d 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 7e382353373b9775666ae915ecb73172f300069d Mon Sep 17 00:00:00 2001 From: Krishna Sannasi Date: Thu, 11 Apr 2019 17:04:02 -0700 Subject: [PATCH 0536/2516] 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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index 41789637dddb3..47412acef7d5b 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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 b527e3b117f5d455ad19fa965cb88949a401e64f Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Tue, 5 Feb 2019 22:36:35 -0800 Subject: [PATCH 0537/2516] subchapter with information about `--error-format json` --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../rustc-dev-guide/src/diag/json-format.md | 36 +++++++++++++++++++ 2 files changed, 37 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/diag/json-format.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index d3cef1a25498b..099c65a738fbd 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diag/json-format.md b/src/doc/rustc-dev-guide/src/diag/json-format.md new file mode 100644 index 0000000000000..6ba555b1dc53c --- /dev/null +++ b/src/doc/rustc-dev-guide/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 9f71565d8f7bd2b2327ed033cd882ba1639dbf28 Mon Sep 17 00:00:00 2001 From: Alexey Shmalko Date: Tue, 16 Apr 2019 00:52:08 +0300 Subject: [PATCH 0538/2516] 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/doc/rustc-dev-guide/src/query.md | 76 ++++++++++++++++------------ 1 file changed, 44 insertions(+), 32 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 703c560e0c218..4d80187aaeef3 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 e300ba3a17cfb0665d60e6ba919e9a8da7bcbb55 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 16 Apr 2019 15:29:25 -0500 Subject: [PATCH 0539/2516] fix MovePathIndex link --- .../moves_and_initialization/move_paths.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index 8fd7b3f196f2c..4d4db4116d4fc 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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 7822fc91dc79e3a84b9c1d9151ce6d6ccb08bae4 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 16 Apr 2019 14:13:38 -0500 Subject: [PATCH 0540/2516] move to subsection --- src/doc/rustc-dev-guide/src/diag.md | 37 +++++++++++++++++++ .../rustc-dev-guide/src/diag/json-format.md | 36 ------------------ 2 files changed, 37 insertions(+), 36 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diag.md index cfdd82aa2a9e3..31268e9f6fa7e 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diag/json-format.md b/src/doc/rustc-dev-guide/src/diag/json-format.md index 6ba555b1dc53c..e69de29bb2d1d 100644 --- a/src/doc/rustc-dev-guide/src/diag/json-format.md +++ b/src/doc/rustc-dev-guide/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 8522ac2305ce41a7c19b38bb4519b6f66b58bc42 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 16 Apr 2019 15:18:55 -0500 Subject: [PATCH 0541/2516] update chalk with new organization --- .../src/traits/chalk-overview.md | 51 ++++++++++--------- .../src/traits/lowering-rules.md | 6 +-- src/doc/rustc-dev-guide/src/traits/wf.md | 10 ++-- 3 files changed, 34 insertions(+), 33 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 54046b22e400f..4d1260ddccc2d 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md index 88a61ac4fa3f5..7f46e5738d479 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md index f0cb03caab246..e2d15f1db010d 100644 --- a/src/doc/rustc-dev-guide/src/traits/wf.md +++ b/src/doc/rustc-dev-guide/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 43ac079bd120b1adc378f7f0e4dce62784ff736f Mon Sep 17 00:00:00 2001 From: Alexey Shmalko Date: Wed, 17 Apr 2019 11:55:14 +0300 Subject: [PATCH 0542/2516] 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. --- .../rustc-dev-guide/src/test-implementation.md | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/test-implementation.md b/src/doc/rustc-dev-guide/src/test-implementation.md index 3c93ad619ee21..969d6d2e49dbb 100644 --- a/src/doc/rustc-dev-guide/src/test-implementation.md +++ b/src/doc/rustc-dev-guide/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 2995bd63bbc8e03746ca5f8985b9763e27ea92c1 Mon Sep 17 00:00:00 2001 From: Alexey Shmalko Date: Thu, 18 Apr 2019 16:51:47 +0300 Subject: [PATCH 0543/2516] Update BodyId description It is now a newtype'd HirId, not NodeId. See https://github.com/rust-lang/rust/pull/58167. --- src/doc/rustc-dev-guide/src/hir.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 34e478ee4d0a1..b100422701188 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 79bf9918453628017999c723bbdedbebf4fd2a0d Mon Sep 17 00:00:00 2001 From: Alexey Shmalko Date: Sat, 20 Apr 2019 23:00:13 +0300 Subject: [PATCH 0544/2516] [canonicalization] fix result canonicalization example --- .../rustc-dev-guide/src/traits/canonical-queries.md | 2 +- src/doc/rustc-dev-guide/src/traits/canonicalization.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md index cbf7d880d0d59..e15bdaae25c43 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md index ca81d6fd16677..d6d57d78509d0 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonicalization.md +++ b/src/doc/rustc-dev-guide/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 b5c8c845d268f95a97735eae7237c94de074d97a Mon Sep 17 00:00:00 2001 From: Alexey Shmalko Date: Sat, 20 Apr 2019 20:08:00 +0300 Subject: [PATCH 0545/2516] Update lowering-module test case --- .../src/traits/lowering-module.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md index 93948405113ff..3f1515ef8afb0 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-module.md +++ b/src/doc/rustc-dev-guide/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 e7ca811a65b4136f8860714751883ce4b959fb08 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 24 Apr 2019 15:57:47 +0200 Subject: [PATCH 0546/2516] Explain new powers of the `treat-err-as-bug` flag --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index bce5959dcf96d..2e45e5f023be4 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 b90995e153166e37b6ac01fc896139726ec65f3c Mon Sep 17 00:00:00 2001 From: Matthew Jasper Date: Wed, 24 Apr 2019 20:53:08 +0100 Subject: [PATCH 0547/2516] Add documentation for two-phase borrows --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/borrow_check/two_phase_borrows.md | 100 ++++++++++++++++++ 2 files changed, 101 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 099c65a738fbd..477b9a7073dec 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md b/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md new file mode 100644 index 0000000000000..753ffa5b2861d --- /dev/null +++ b/src/doc/rustc-dev-guide/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 20a14c37b1e00fcb880214ba535c5e09a5421cf0 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 0548/2516] Fixed broken chalk links --- src/doc/rustc-dev-guide/src/traits/lowering-rules.md | 4 ++-- src/doc/rustc-dev-guide/src/traits/wf.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md index 7f46e5738d479..bbebf1450a23e 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md index e2d15f1db010d..0ced345a151cc 100644 --- a/src/doc/rustc-dev-guide/src/traits/wf.md +++ b/src/doc/rustc-dev-guide/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 20a751a924e274f674a15b826a20857119e08ddc Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 25 Apr 2019 20:18:55 -0500 Subject: [PATCH 0549/2516] use nightly rust for ci --- src/doc/rustc-dev-guide/.travis.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 55ea2058764c4..fc6f4f05e571b 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.travis.yml @@ -1,4 +1,6 @@ language: rust +rust: +- nightly cache: - cargo before_install: From a6907e1551faba01c9c39b8e0ded72f8fc651c07 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Mon, 29 Apr 2019 07:26:21 -0700 Subject: [PATCH 0550/2516] 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/doc/rustc-dev-guide/src/codegen/updating-llvm.md b/src/doc/rustc-dev-guide/src/codegen/updating-llvm.md index e29e041b2b7a7..b26c475f76790 100644 --- a/src/doc/rustc-dev-guide/src/codegen/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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 547f42705c728c2a38755c6a88a291f55a244c33 Mon Sep 17 00:00:00 2001 From: Nicolas Date: Wed, 1 May 2019 03:58:22 -0300 Subject: [PATCH 0551/2516] Remove IRC from discussion chats --- src/doc/rustc-dev-guide/src/compiler-team.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index b837c038ccb80..0f0808b79af6a 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 17f33c6bae054f91f647fc7cf0ac5af9c73ba10f Mon Sep 17 00:00:00 2001 From: guilherme Date: Fri, 26 Apr 2019 23:47:16 +0100 Subject: [PATCH 0552/2516] Fix link in walkthrough --- src/doc/rustc-dev-guide/src/walkthrough.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 2823426be1008..e2e96fced9fb0 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 81c0312f6126a751e39e38dea050b0448d0964ad 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 0553/2516] Added mention of universal ctags --- .../rustc-dev-guide/src/how-to-build-and-run.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 241852b19daab..6d5bcb916badd 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 fae4a0412d755d6bb2a270034ae5b1b9ccbb5a9b Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 3 May 2019 15:45:04 +0900 Subject: [PATCH 0554/2516] Rename to RUSTC_LOG --- .../rustc-dev-guide/src/compiler-debugging.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 2e45e5f023be4..db7f08e4655ff 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 73df716b8f7eab7314fb17c849376402810b17e1 Mon Sep 17 00:00:00 2001 From: Tom Mulvaney Date: Wed, 17 Apr 2019 18:29:11 +0100 Subject: [PATCH 0555/2516] Fix typo, 'which' repeated twice --- src/doc/rustc-dev-guide/src/traits/chalk-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 4d1260ddccc2d..54f6c33949e36 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 58e8eb91b419d8f75ca3a611e422edc72caafde2 Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Tue, 14 May 2019 13:10:04 +0200 Subject: [PATCH 0556/2516] Add documentation about profile-guided optimization. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/profile-guided-optimization.md | 132 ++++++++++++++++++ 2 files changed, 133 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/profile-guided-optimization.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 477b9a7073dec..c33d15f3cccef 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profile-guided-optimization.md b/src/doc/rustc-dev-guide/src/profile-guided-optimization.md new file mode 100644 index 0000000000000..fb897e901ef96 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 c4fd51510bec13de3f301277d8fb1149acb0416f 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 0557/2516] 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/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 54f6c33949e36..0a95585f6d718 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 0d42484b595d67e750249a4a002005f5766c8228 Mon Sep 17 00:00:00 2001 From: varkor Date: Wed, 15 May 2019 08:58:20 +0100 Subject: [PATCH 0558/2516] Mention running tests for subdirectories --- .../src/how-to-build-and-run.md | 4 ++++ src/doc/rustc-dev-guide/src/tests/running.md | 21 ++++++++++++++++--- 2 files changed, 22 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 6d5bcb916badd..9b205c7b19968 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 1250fa77b7a90..5a05c156f92e0 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 fcc10c5111350527d3ec096890d135e343ad8359 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 0559/2516] Added rustc phases diagram and explanation Added rustc build phase diagram and explanation --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- .../src/how-to-build-and-run.md | 270 +++++++++++++++--- .../rustc-dev-guide/src/img/rustc_stages.svg | 2 + 3 files changed, 230 insertions(+), 44 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/img/rustc_stages.svg diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index c33d15f3cccef..ca8f4adaa7621 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 9b205c7b19968..4eb4023c4ec0f 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/img/rustc_stages.svg b/src/doc/rustc-dev-guide/src/img/rustc_stages.svg new file mode 100644 index 0000000000000..b6671aa7cc4b2 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 f0357ad4b8af84aead4ced0a2547c46403c4a3db Mon Sep 17 00:00:00 2001 From: Julian Wollersberger Date: Fri, 17 May 2019 17:38:29 +0200 Subject: [PATCH 0560/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 4 ++-- src/doc/rustc-dev-guide/src/appendix/code-index.md | 2 +- src/doc/rustc-dev-guide/src/{diag.md => diagnostics.md} | 2 +- .../rustc-dev-guide/src/{diag => diagnostics}/json-format.md | 0 src/doc/rustc-dev-guide/src/implementing_new_features.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) rename src/doc/rustc-dev-guide/src/{diag.md => diagnostics.md} (99%) rename src/doc/rustc-dev-guide/src/{diag => diagnostics}/json-format.md (100%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index ca8f4adaa7621..3d5dd44b6572f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 3c71d6bbaa641..222c9b2dbe5b8 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diag.md b/src/doc/rustc-dev-guide/src/diagnostics.md similarity index 99% rename from src/doc/rustc-dev-guide/src/diag.md rename to src/doc/rustc-dev-guide/src/diagnostics.md index 31268e9f6fa7e..f3d51876472ad 100644 --- a/src/doc/rustc-dev-guide/src/diag.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diag/json-format.md b/src/doc/rustc-dev-guide/src/diagnostics/json-format.md similarity index 100% rename from src/doc/rustc-dev-guide/src/diag/json-format.md rename to src/doc/rustc-dev-guide/src/diagnostics/json-format.md diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 8105e1474a611..6d1327fabb7f6 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 586cbf157ff2baee7f4d16e18723139329527118 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 28 May 2019 17:13:08 -0300 Subject: [PATCH 0561/2516] Add more info subsection with links to forge and rustc api docs --- src/doc/rustc-dev-guide/src/about-this-guide.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 30a3b88708f0b..8376fb2a3914d 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 ddb5a4090c73b18d37c8eaf511ceb87578d40c42 Mon Sep 17 00:00:00 2001 From: Vallentin Date: Thu, 30 May 2019 21:09:46 +0200 Subject: [PATCH 0562/2516] Fixed misspelling --- .../src/borrow_check/moves_and_initialization.md | 2 +- .../src/queries/query-evaluation-model-in-detail.md | 2 +- src/doc/rustc-dev-guide/src/traits/slg.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md index d1530d6c09056..043db2f5354e5 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index 47412acef7d5b..7772f36beaa04 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/slg.md b/src/doc/rustc-dev-guide/src/traits/slg.md index 98547575dc9ce..948d3fc8ab1bd 100644 --- a/src/doc/rustc-dev-guide/src/traits/slg.md +++ b/src/doc/rustc-dev-guide/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 19022db2d43c3789d34252db9780304bc8aff4f8 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 2 Jun 2019 19:28:14 -0500 Subject: [PATCH 0563/2516] fix long line --- src/doc/rustc-dev-guide/src/about-this-guide.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 8376fb2a3914d..df060a208864b 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 85601df5ef705d2c4b261e7f134549228942f19b Mon Sep 17 00:00:00 2001 From: Vadim Petrochenkov Date: Fri, 31 May 2019 13:54:39 +0400 Subject: [PATCH 0564/2516] Update information about debuginfo configuration --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 2 +- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 8 +++----- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 8 ++++---- 3 files changed, 8 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index db7f08e4655ff..304f75d802a91 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 4eb4023c4ec0f..d0ba0ea57f28d 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 25889940029c3..2634cc2601ab2 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 d2d5d7e0dbc43ce89ef42833410db12b0e146ecc Mon Sep 17 00:00:00 2001 From: mdsimmo Date: Tue, 4 Jun 2019 13:44:58 +1000 Subject: [PATCH 0565/2516] correct indentation Indentation consistently 4 spaces and Part 1/Part2 contain everything else --- src/doc/rustc-dev-guide/src/SUMMARY.md | 157 ++++++++++++------------- 1 file changed, 77 insertions(+), 80 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 3d5dd44b6572f..2b519da7537af 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 98ec4f7322c5b01cb647af50fb4512a3f19e1dc8 Mon Sep 17 00:00:00 2001 From: mdsimmo Date: Tue, 4 Jun 2019 14:11:06 +1000 Subject: [PATCH 0566/2516] Replaced tabs with spaces --- src/doc/rustc-dev-guide/src/SUMMARY.md | 154 ++++++++++++------------- 1 file changed, 77 insertions(+), 77 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 2b519da7537af..e838985209d5e 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 cfb697525cce974324bae94eb01835223a128105 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 7 Jun 2019 15:34:08 -0500 Subject: [PATCH 0567/2516] use debug instead of debuginfo-level --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index d0ba0ea57f28d..ca9065ced8ead 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 32921f754ccfe6aa73d94b087627efb2058eb17c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 7 Jun 2019 15:51:16 -0500 Subject: [PATCH 0568/2516] Update compiler-debugging.md --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 304f75d802a91..0126c250345bf 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 3a559465dcafbf63801b4a9bf37bfee97007fe3a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 7 Jun 2019 16:06:09 -0500 Subject: [PATCH 0569/2516] Update how-to-build-and-run.md --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index ca9065ced8ead..e0ce70111ace3 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 f5b41c3400bf84be2f826fd373772db11419a83a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 7 Jun 2019 16:07:45 -0500 Subject: [PATCH 0570/2516] Update how-to-build-and-run.md --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index e0ce70111ace3..f44179bc9ca2b 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 b3c33960dd41ce9a5d4c81270a23d502f4c5f454 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 12 Jun 2019 17:00:07 -0300 Subject: [PATCH 0571/2516] Add triagebot --- src/doc/rustc-dev-guide/triagebot.toml | 1 + 1 file changed, 1 insertion(+) create mode 100644 src/doc/rustc-dev-guide/triagebot.toml diff --git a/src/doc/rustc-dev-guide/triagebot.toml b/src/doc/rustc-dev-guide/triagebot.toml new file mode 100644 index 0000000000000..fa0824ac53c0a --- /dev/null +++ b/src/doc/rustc-dev-guide/triagebot.toml @@ -0,0 +1 @@ +[assign] From b0c8a0324597747b344afc0952f0c3dac2c29eea Mon Sep 17 00:00:00 2001 From: Jonas Schievink Date: Wed, 12 Jun 2019 20:01:27 +0200 Subject: [PATCH 0572/2516] Fix a few typos in type inference chapter Also try to test the top example --- src/doc/rustc-dev-guide/src/type-inference.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index a3d012b5dff7b..d94c063799dda 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 b394ba60aea18186ad7647607a50d55a447a0957 Mon Sep 17 00:00:00 2001 From: Jonathan Behrens Date: Sat, 8 Jun 2019 19:11:04 -0400 Subject: [PATCH 0573/2516] Changes to config.toml require a clean --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index f44179bc9ca2b..92fbcb0fd8afb 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 1e6ab9e7ffc3b2833111a7f1531a36105c0a6faa Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 15 Jun 2019 16:08:35 -0500 Subject: [PATCH 0574/2516] add note about rebuilding llvm --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 92fbcb0fd8afb..84efffc84b8d0 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 34ba6e890d6ef571d415b1605aa921f6fb21fa75 Mon Sep 17 00:00:00 2001 From: Blitzerr Date: Thu, 1 Nov 2018 22:14:05 -0700 Subject: [PATCH 0575/2516] Notes about closure de-sugaring --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/closure.md | 159 +++++++++++++++++++++++++ 2 files changed, 160 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/closure.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index e838985209d5e..273b409ec8cd5 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md new file mode 100644 index 0000000000000..3bf96598326c5 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 e6c3362e9097235a5eb75a65e9b4c6da2965de71 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 23 Mar 2019 13:47:03 -0500 Subject: [PATCH 0576/2516] Some edits to address review comments --- src/doc/rustc-dev-guide/src/closure.md | 174 ++++++++++++++++--------- 1 file changed, 114 insertions(+), 60 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index 3bf96598326c5..a31893b0acac7 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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 b10dac3953cafdf1448bcdeade73d15543bdb17b Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 15 Jun 2019 16:54:08 -0500 Subject: [PATCH 0577/2516] fix ci failures, typos, broken links --- .../rustc-dev-guide/src/borrow_check/two_phase_borrows.md | 2 +- src/doc/rustc-dev-guide/src/closure.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md b/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md index 753ffa5b2861d..09e7fbefe5f68 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index a31893b0acac7..77f2b42c34655 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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 13d4f556ee29af1ff02681734e9667d12344652e Mon Sep 17 00:00:00 2001 From: Eduard-Mihai Burtescu Date: Fri, 14 Jun 2019 19:17:23 +0300 Subject: [PATCH 0578/2516] Update for TyCtxt<'a, 'gcx, 'tcx> -> TyCtxt<'tcx>. --- .../src/appendix/code-index.md | 2 +- .../rustc-dev-guide/src/appendix/glossary.md | 1 - .../rustc-dev-guide/src/compiler-debugging.md | 10 ++-- src/doc/rustc-dev-guide/src/conventions.md | 3 +- src/doc/rustc-dev-guide/src/mir/visitor.md | 2 +- .../src/profiling/with_perf.md | 6 +- src/doc/rustc-dev-guide/src/query.md | 16 +++-- src/doc/rustc-dev-guide/src/ty.md | 58 +++---------------- src/doc/rustc-dev-guide/src/type-inference.md | 5 +- 9 files changed, 27 insertions(+), 76 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 222c9b2dbe5b8..52a7f42d6f956 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index a5d5bf56aa684..46c5c9f0f6d6c 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 0126c250345bf..8f3a331aa687e 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index d9f462a053739..a941ebff967c6 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/visitor.md b/src/doc/rustc-dev-guide/src/mir/visitor.md index ad00bc3f16a19..a5e8e9a0b6135 100644 --- a/src/doc/rustc-dev-guide/src/mir/visitor.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 2634cc2601ab2..7582eece5630a 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 4d80187aaeef3..4ab1d079ec14b 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index d9979bc0b4dc0..72405d2971cf3 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index d94c063799dda..d4734525f75b3 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 bc4c9c0560891dc2531d14e8734cc07718143bc5 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 15 Jun 2019 17:00:21 -0500 Subject: [PATCH 0579/2516] fix typos --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- src/doc/rustc-dev-guide/src/conventions.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 46c5c9f0f6d6c..3d77def919508 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index a941ebff967c6..3660f33790829 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 92c8e63c6679c314336e00870f1cabcaa183ccd5 Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Sun, 5 May 2019 15:15:09 -0400 Subject: [PATCH 0580/2516] Added Rustc Debugger Support Chapter --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/debugging-support-in-rustc.md | 321 ++++++++++++++++++ 2 files changed, 322 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 273b409ec8cd5..663357f0052f1 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/debugging-support-in-rustc.md b/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md new file mode 100644 index 0000000000000..1775b07af54c9 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 910c73f187059612b77fdf3d74e6d8920bf98cf2 Mon Sep 17 00:00:00 2001 From: b41sh Date: Mon, 24 Jun 2019 21:43:27 +0800 Subject: [PATCH 0581/2516] fix compiler-team --- src/doc/rustc-dev-guide/src/compiler-team.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index 0f0808b79af6a..968e2f142914b 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 78a513d400e218b367404c4444f2105cac569121 Mon Sep 17 00:00:00 2001 From: flip1995 Date: Mon, 24 Jun 2019 12:59:12 +0200 Subject: [PATCH 0582/2516] Change stage0 cfg_attr to bootstrap --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 56da5cdaf1667..76446150c4069 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 577be7148cf5c1717e5874260846384e590d62e3 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 19 Jun 2019 13:11:01 -0500 Subject: [PATCH 0583/2516] Update mdbook --- src/doc/rustc-dev-guide/ci/install.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 835f231925157..d22d2c6c13e3c 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 2eb100a28bb7476d55682656c1b8d3656b8612d6 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 21 Jun 2019 09:57:52 -0500 Subject: [PATCH 0584/2516] Update to mdbook-linkcheck 0.3.0 --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index d22d2c6c13e3c..7c730cae33506 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 5ab16e46ce51e7889d3bb77329c3445eb2874776 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 25 Jun 2019 15:16:30 -0500 Subject: [PATCH 0585/2516] add bibligraphy appendix --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/appendix/bibliography.md | 89 +++++++++++++++++++ 2 files changed, 90 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/appendix/bibliography.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 663357f0052f1..45b05c0c9fed5 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md new file mode 100644 index 0000000000000..64e014f91c07e --- /dev/null +++ b/src/doc/rustc-dev-guide/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 b28310b8307b5ef4eac46af85b6f0ae765540be4 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 10:32:01 -0500 Subject: [PATCH 0586/2516] fix broken links --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index 64e014f91c07e..a5bd84b2505df 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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 b145f3d93504226ac44167024e6069e14b9f2721 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 10:41:07 -0500 Subject: [PATCH 0587/2516] avoid ftp links --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index a5bd84b2505df..19a9217f70a5f 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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 c91e8afe850593b1be1aa1972dce05f3a7234b7d Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 18 Jun 2019 10:08:04 -0400 Subject: [PATCH 0588/2516] fix typo --- src/doc/rustc-dev-guide/src/borrow_check/region_inference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 7fe50b870c71c..fc39784362349 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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 053fad2bbe936e8508e49d67ee1fd06f2fc0dd3b Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 18 Jun 2019 10:17:36 -0400 Subject: [PATCH 0589/2516] break out parts of the region inference chapter into sub-chapters --- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/closure_constraints.md create mode 100644 src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md create mode 100644 src/doc/rustc-dev-guide/src/borrow_check/region_inference/error_reporting.md create mode 100644 src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 45b05c0c9fed5..7e9a9ee54c69c 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index fc39784362349..5279d210ba353 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/closure_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/closure_constraints.md new file mode 100644 index 0000000000000..13230d037cd17 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md new file mode 100644 index 0000000000000..2e69629b16fa3 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/error_reporting.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/error_reporting.md new file mode 100644 index 0000000000000..79b3e077c7bca --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md new file mode 100644 index 0000000000000..0d4068e000241 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 99188aef5cad315426f61630d3bf7045c90c2e12 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 18 Jun 2019 10:55:07 -0400 Subject: [PATCH 0590/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 2e69629b16fa3..ce01764c4fdfe 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 5c7f94fae0b2bee5d6364085ecbf6155f8ef419f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 20 Jun 2019 09:43:48 -0400 Subject: [PATCH 0591/2516] describe region inference and member constraints in some detail --- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md create mode 100644 src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 7e9a9ee54c69c..69e46b7960728 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 5279d210ba353..e9f0e35e3dc68 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index ce01764c4fdfe..e2c36062fdbb4 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md new file mode 100644 index 0000000000000..10759ee56cda9 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md new file mode 100644 index 0000000000000..4d73126442591 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 66a57fc7f324afa193572c04379d7b839dd6078c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 20 Jun 2019 09:51:11 -0400 Subject: [PATCH 0592/2516] adjust overview slightly --- .../src/borrow_check/region_inference.md | 27 ++++++++++--------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index e9f0e35e3dc68..46caab567c1b0 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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 a8b5b2176576b0e9835b6b4117294db7e2c193d2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:32:53 -0400 Subject: [PATCH 0593/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index e2c36062fdbb4..385e04892ae85 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 36431d5ff651c53957ca367b25b5ea9d59f81332 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:02 -0400 Subject: [PATCH 0594/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index 10759ee56cda9..1a50f45f9fda3 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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 45a55e7c88b5d814e9a5673c2d248fa7920f9cc4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:15 -0400 Subject: [PATCH 0595/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index 1a50f45f9fda3..798af13378a3f 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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 44cf84b75301f778a3cee81687c6d6bf24675e03 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:24 -0400 Subject: [PATCH 0596/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index 798af13378a3f..aa36d7dbb8fe1 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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 11a964ab17dfc254d5397d1e16d978b618d89d67 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:33 -0400 Subject: [PATCH 0597/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 385e04892ae85..88fb00a7daf69 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 6623226c3b9897bd19f5ae95c24565c9adad115f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:41 -0400 Subject: [PATCH 0598/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 88fb00a7daf69..87a72eb1db359 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 94acf38fbb8a6e8bc2e07625be6eda72d3b88993 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:49 -0400 Subject: [PATCH 0599/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 87a72eb1db359..95266a48627b3 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 52e3d294239167354d9f2e1e7974485f44b2e77b Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:57 -0400 Subject: [PATCH 0600/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 95266a48627b3..3ec374b6688e4 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 cce253efe739974be3c516bc4d2aeacad2b3a2ae Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:34:05 -0400 Subject: [PATCH 0601/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 3ec374b6688e4..19af52ec43aec 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 2467a1daa668a9abb3bf28cdfe354efa4c01b218 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:34:15 -0400 Subject: [PATCH 0602/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 19af52ec43aec..06cee8ad8febb 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 0c3b78c1090ef56f9c4b9cf02341c84c8030f660 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:34:22 -0400 Subject: [PATCH 0603/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 06cee8ad8febb..e86d850fa6115 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 f6c79d7467dd78e2d019725d009c03d6bbe5f9b5 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:34:32 -0400 Subject: [PATCH 0604/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index 4d73126442591..5e62d512576c6 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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 c6d975df8d9e10bdcebf05cd58b608899fbb3a3e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:34:40 -0400 Subject: [PATCH 0605/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index aa36d7dbb8fe1..ecd3a19a5b71f 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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 59be36693e4f5d350dae08e162f25b054a0ff81e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:35:04 -0400 Subject: [PATCH 0606/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index 5e62d512576c6..1d5fb10134476 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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 4937aed1a7332cfc1095077196442ec4377ef88e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:35:17 -0400 Subject: [PATCH 0607/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index 1d5fb10134476..219296d0ddf7b 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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 b1169deec375b473a7e50afd71f379c8a8ffe5e0 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:35:37 -0400 Subject: [PATCH 0608/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index e86d850fa6115..c655df9598d12 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 f234ab9da30b81f47ad4cc3f88509b2775f66dac Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:35:48 -0400 Subject: [PATCH 0609/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index 219296d0ddf7b..48b24d2152b99 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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 ed00d21c888855887982b42de893962fb867f574 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:35:59 -0400 Subject: [PATCH 0610/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index c655df9598d12..54f2c4cfd611a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 6bcafb7bfac5d4f5f23e254d77fe01b576a05f26 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:36:59 -0400 Subject: [PATCH 0611/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index 48b24d2152b99..3f934e8642d80 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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 2ea7e83d4d0fdf4ea10d5626577f99de82a483ef Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:37:12 -0400 Subject: [PATCH 0612/2516] Update src/borrow_check/region_inference/placeholders_and_universes.md Co-Authored-By: Who? Me?! --- .../borrow_check/region_inference/placeholders_and_universes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md index 0d4068e000241..cc262ad3eb3c4 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/doc/rustc-dev-guide/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 2e1e8c8945472ac90eeb8b4187bfdda3fdba2b99 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:37:22 -0400 Subject: [PATCH 0613/2516] Update src/borrow_check/region_inference/placeholders_and_universes.md Co-Authored-By: Who? Me?! --- .../borrow_check/region_inference/placeholders_and_universes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md index cc262ad3eb3c4..57fae404bf4d7 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/doc/rustc-dev-guide/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 96a81f83a6bff7eeec137f2e2d599830eeeb24b1 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:37:30 -0400 Subject: [PATCH 0614/2516] Update src/borrow_check/region_inference/placeholders_and_universes.md Co-Authored-By: Who? Me?! --- .../borrow_check/region_inference/placeholders_and_universes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md index 57fae404bf4d7..604c793d573b0 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/doc/rustc-dev-guide/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 58dcee422bbc1de40f617ae536cc2c911cd46d37 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:41:25 -0400 Subject: [PATCH 0615/2516] fix indentation --- .../region_inference/placeholders_and_universes.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md index 604c793d573b0..e40ee11b19f3a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/doc/rustc-dev-guide/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 1231e23b54a683b87c0f896568659c447c36e179 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:44:13 -0400 Subject: [PATCH 0616/2516] add `point` to the glossary and link a use of it --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + .../borrow_check/region_inference/constraint_propagation.md | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 3d77def919508..007b1bb4cdc68 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 54f2c4cfd611a..7b9eeb13d4c45 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 77e2fb18222924d3f6b52b227a07be2521c1c007 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 11:03:43 -0500 Subject: [PATCH 0617/2516] fix long line --- src/doc/rustc-dev-guide/src/SUMMARY.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 69e46b7960728..8c8890b7993d7 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 09c36b31eb25224227639bd21c7cd64ad981f8b7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 14:26:14 -0500 Subject: [PATCH 0618/2516] fix links --- .../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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 7b9eeb13d4c45..daa52393a021a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md index e40ee11b19f3a..eda8e6ff1dd3a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/doc/rustc-dev-guide/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 e94168ce8719332cd7a50921aea4e697ea2de50b Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 14:34:56 -0500 Subject: [PATCH 0619/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index daa52393a021a..a8e44629e8d6a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index ecd3a19a5b71f..87e9d53ed8bd4 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index 3f934e8642d80..d69c95511d3c3 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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 b441d2fa894c64c757798ab50a6fa6c21a5129f7 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 27 Jun 2019 05:45:00 +0900 Subject: [PATCH 0620/2516] Fix typo --- src/doc/rustc-dev-guide/src/mir/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index baaf23c36974f..9e9f933fe8183 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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 f6419de669d31900a633f527059edf08a2b37aab Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 4 Jul 2019 20:39:45 +0900 Subject: [PATCH 0621/2516] Update pass modes for ui tests (#380) --- src/doc/rustc-dev-guide/src/tests/adding.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 5b86748142a0d..d88b7cf574919 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 67c81f16f54ad5d602c0dbd3c5011d04b902a981 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 4 Jul 2019 20:41:50 +0900 Subject: [PATCH 0622/2516] Fix broken links (#382) --- .../borrow_check/region_inference/constraint_propagation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index a8e44629e8d6a..7ec46b90f8306 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 cfc17deefba7e96b6bc89783812920c638e4f886 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 10:58:05 -0500 Subject: [PATCH 0623/2516] add humor appendix; closes #163 --- src/doc/rustc-dev-guide/src/SUMMARY.md | 5 +++++ src/doc/rustc-dev-guide/src/appendix/humorust.md | 10 ++++++++++ 2 files changed, 15 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/appendix/humorust.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 8c8890b7993d7..e321f6633a362 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md new file mode 100644 index 0000000000000..e217ab65fe0ed --- /dev/null +++ b/src/doc/rustc-dev-guide/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 700bdd56f3a861be674755de09fb11f551018550 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 17 Jul 2019 22:02:05 +0900 Subject: [PATCH 0624/2516] Update experts' link --- src/doc/rustc-dev-guide/src/compiler-team.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index 968e2f142914b..f01b4a8d55846 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 bbcbfc70625f8cdea13b1e74978e98513fc60066 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 17 Jul 2019 10:10:43 -0500 Subject: [PATCH 0625/2516] blacklist some commonly problematic links --- src/doc/rustc-dev-guide/book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index b9092a969c229..856ef2eba1341 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 72ef7f9094f0652798c729f760baf278500198cc Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 12 Jul 2019 11:44:03 +0900 Subject: [PATCH 0626/2516] Document `--pass $mode` --- src/doc/rustc-dev-guide/src/tests/running.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 5a05c156f92e0..01d308f0b9227 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 e0964af5d5730c72b9608357d170521fd0f09012 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 12 Jul 2019 11:02:45 +0900 Subject: [PATCH 0627/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference.md | 1 - .../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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index 4d4db4116d4fc..d733e8ac7f1e7 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 46caab567c1b0..52659e93c032a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 7ec46b90f8306..5f3b29c6d342a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index 87e9d53ed8bd4..0d5219aa9651e 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index d69c95511d3c3..7e254f0a25b4e 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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 2d2f8140b3d921feed97266e178e627c250462a0 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 12 Jul 2019 11:58:41 +0900 Subject: [PATCH 0628/2516] Move into rust-lang --- src/doc/rustc-dev-guide/README.md | 2 +- src/doc/rustc-dev-guide/src/traits/index.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index e6230439e9179..064f80c6e4d9e 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/index.md b/src/doc/rustc-dev-guide/src/traits/index.md index 84f812394bf8a..5544ce513d00c 100644 --- a/src/doc/rustc-dev-guide/src/traits/index.md +++ b/src/doc/rustc-dev-guide/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 c5116dafd15df8a46698c4142fec69eb3ba35430 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 12 Jul 2019 12:00:12 +0900 Subject: [PATCH 0629/2516] Add colon --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index e321f6633a362..60aa8766db114 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 f329a97adf0e5726a5c68db87e0d758423aa2ece Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 17 Jul 2019 12:01:32 -0500 Subject: [PATCH 0630/2516] break rust --- src/doc/rustc-dev-guide/src/appendix/humorust.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md index e217ab65fe0ed..f044a50c06637 100644 --- a/src/doc/rustc-dev-guide/src/appendix/humorust.md +++ b/src/doc/rustc-dev-guide/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 d2733c2854cb083c503013e13ba4ccdf31ac7a4c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 17 Jul 2019 12:04:18 -0500 Subject: [PATCH 0631/2516] add nomicon intro too --- src/doc/rustc-dev-guide/src/appendix/humorust.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md index f044a50c06637..36c25c89067cd 100644 --- a/src/doc/rustc-dev-guide/src/appendix/humorust.md +++ b/src/doc/rustc-dev-guide/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 92e36bf443aed329d305ee99ab88bbef6ccec7eb Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 19 Jul 2019 11:09:23 -0500 Subject: [PATCH 0632/2516] Update mdbook --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 7c730cae33506..be64d1ee831f0 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 b6f07d808b54d5525de2dd42ab78bacb7fd137f2 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 19 Jul 2019 11:23:56 -0500 Subject: [PATCH 0633/2516] Update install.sh --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index be64d1ee831f0..48df957f97555 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 324327a178facaca143383776316f705085ac59b Mon Sep 17 00:00:00 2001 From: Ilija Tovilo Date: Sat, 20 Jul 2019 20:12:03 +0200 Subject: [PATCH 0634/2516] Fix typo --- .../src/queries/query-evaluation-model-in-detail.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index 7772f36beaa04..a1fbed2e54813 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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 d464714712da9e3160d5c0647ca3c0d30ea85516 Mon Sep 17 00:00:00 2001 From: Ilija Tovilo Date: Sun, 21 Jul 2019 23:47:05 +0200 Subject: [PATCH 0635/2516] Fix typo --- src/doc/rustc-dev-guide/src/closure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index 77f2b42c34655..e73f2e168dce9 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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 d38a090739839fab180b6c618dd3c9cd41eded3f Mon Sep 17 00:00:00 2001 From: Ilija Tovilo Date: Sun, 21 Jul 2019 12:37:42 +0200 Subject: [PATCH 0636/2516] Fix macro syntax error --- src/doc/rustc-dev-guide/src/macro-expansion.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index c62301247a62a..bb429282f4edf 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 14c1b0607c18842c5c929c31d8dad3a1694ed189 Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Sun, 21 Jul 2019 14:33:57 +0300 Subject: [PATCH 0637/2516] write a short paragraph about the new lexer --- src/doc/rustc-dev-guide/src/the-parser.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index ac902d91547a4..5796ae40ec0b0 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 12227be97c8f800466b0228ea7d6fac350a808ec Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 24 Jul 2019 18:03:40 -0300 Subject: [PATCH 0638/2516] 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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index d733e8ac7f1e7..157a9eaf3e8ac 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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 df96d6fbca1db3d87b4fee056ad31518e2bd221e Mon Sep 17 00:00:00 2001 From: Brian Foley Date: Thu, 25 Jul 2019 15:25:26 -0700 Subject: [PATCH 0639/2516] Fix miscellaneous spelling typos. (#397) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- src/doc/rustc-dev-guide/src/borrow_check/region_inference.md | 2 +- src/doc/rustc-dev-guide/src/closure.md | 2 +- src/doc/rustc-dev-guide/src/codegen/updating-llvm.md | 2 +- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 4 ++-- src/doc/rustc-dev-guide/src/kinds.md | 2 +- src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md | 2 +- src/doc/rustc-dev-guide/src/traits/implied-bounds.md | 2 +- 9 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 60aa8766db114..75e1fcdc24bb6 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 007b1bb4cdc68..3375d035f72c2 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 52659e93c032a..216128ffb817e 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index e73f2e168dce9..c47ad9bc8a4a8 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen/updating-llvm.md b/src/doc/rustc-dev-guide/src/codegen/updating-llvm.md index b26c475f76790..50dc949623761 100644 --- a/src/doc/rustc-dev-guide/src/codegen/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 84efffc84b8d0..c3968b591f5a2 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/kinds.md b/src/doc/rustc-dev-guide/src/kinds.md index ac6a2d35b57d7..e4ba729954627 100644 --- a/src/doc/rustc-dev-guide/src/kinds.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index 8f1ffa4882200..a653528f4cdef 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/implied-bounds.md b/src/doc/rustc-dev-guide/src/traits/implied-bounds.md index f32c9d0cbb921..5876f3b62164e 100644 --- a/src/doc/rustc-dev-guide/src/traits/implied-bounds.md +++ b/src/doc/rustc-dev-guide/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 2f1fcd794f2c77bfcfd7b9028ddf06980ba8ea5d Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 1 Aug 2019 15:30:45 -0300 Subject: [PATCH 0640/2516] Fix experts map link --- src/doc/rustc-dev-guide/src/compiler-team.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index f01b4a8d55846..1dbeeb422759b 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 34feb4a16e04bd27e0147ea9b92a0a6fc1cce7d4 Mon Sep 17 00:00:00 2001 From: Bruce Mitchener Date: Fri, 2 Aug 2019 01:47:43 +0700 Subject: [PATCH 0641/2516] Fix broken links. --- src/doc/rustc-dev-guide/src/appendix/humorust.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md index 36c25c89067cd..ef926c1c69eae 100644 --- a/src/doc/rustc-dev-guide/src/appendix/humorust.md +++ b/src/doc/rustc-dev-guide/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 2600e9b42c226fd21030193e944e454a5e1ed174 Mon Sep 17 00:00:00 2001 From: Bruce Mitchener Date: Fri, 2 Aug 2019 01:16:56 +0700 Subject: [PATCH 0642/2516] Fix typos. --- src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md | 2 +- src/doc/rustc-dev-guide/src/kinds.md | 2 +- src/doc/rustc-dev-guide/src/miri.md | 2 +- src/doc/rustc-dev-guide/src/stabilization_guide.md | 6 +++--- src/doc/rustc-dev-guide/src/ty.md | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md b/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md index 1775b07af54c9..3d08cc8253a23 100644 --- a/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/kinds.md b/src/doc/rustc-dev-guide/src/kinds.md index e4ba729954627..194d2ee2ff6c3 100644 --- a/src/doc/rustc-dev-guide/src/kinds.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index d361103f20fba..aee2376f1b982 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 76446150c4069..302be41d0a991 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 72405d2971cf3..811f473c9b5a3 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 8fdbbda3db5fe8d8762197892c95a13691eed309 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 2 Aug 2019 04:25:07 +0200 Subject: [PATCH 0643/2516] run-pass dir is gone (#409) Fixes #405 --- src/doc/rustc-dev-guide/src/compiletest.md | 4 ++-- .../rustc-dev-guide/src/how-to-build-and-run.md | 2 +- src/doc/rustc-dev-guide/src/tests/adding.md | 15 ++++++--------- src/doc/rustc-dev-guide/src/tests/running.md | 8 ++++---- 4 files changed, 13 insertions(+), 16 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 3cfb943b07ed6..1b424e1a24b4d 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index c3968b591f5a2..0a746177bb742 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index d88b7cf574919..a660d26b56d1c 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 01d308f0b9227..ef3227f9abe64 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 de6cb97e4b673ef1ff975eb33d73097074f14925 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 5 Aug 2019 15:57:25 -0500 Subject: [PATCH 0644/2516] hack around timeouts (#416) --- src/doc/rustc-dev-guide/.travis.yml | 4 ++-- .../ci/build-ignore-timeouts.sh | 23 +++++++++++++++++++ 2 files changed, 25 insertions(+), 2 deletions(-) create mode 100644 src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index fc6f4f05e571b..bd72a03fc0ba3 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh b/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh new file mode 100644 index 0000000000000..b21ce24e83f93 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 245e9f0a374cbe7e7e678ca599df62f9795d27af Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 5 Aug 2019 23:03:34 +0200 Subject: [PATCH 0645/2516] a colon there is unusual (#415) --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 0a746177bb742..eb14e8fad19a6 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 113cac6f68f6af5832a4dda1fdd55e24484a0baf Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 5 Aug 2019 23:06:51 +0200 Subject: [PATCH 0646/2516] fix typo (#412) --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index eb14e8fad19a6..8a803e66cc9d6 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 ce22bc6ec1cf91b74017f98a5992369a6ce8f4f5 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 5 Aug 2019 23:07:05 +0200 Subject: [PATCH 0647/2516] update link (#411) --- src/doc/rustc-dev-guide/src/compiler-team.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index 1dbeeb422759b..d611376823931 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 8acf533607adf52116966718882aff0faf5882fe Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 5 Aug 2019 23:07:17 +0200 Subject: [PATCH 0648/2516] fix awkward sentence structure (#410) --- src/doc/rustc-dev-guide/src/about-this-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index df060a208864b..48ea4dce63514 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 1254cf3f040544cd9bf9b749d9b6a287fd219035 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 6 Aug 2019 16:49:01 -0500 Subject: [PATCH 0649/2516] Remove leading new line --- src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh b/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh index b21ce24e83f93..e777f349a3c00 100644 --- a/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh +++ b/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh @@ -1,3 +1,4 @@ +#!/bin/bash -x output=$(mktemp) From 90fa36986175ef3bba8552b3ba80bdd5873f03f0 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 13 Aug 2019 09:56:02 -0500 Subject: [PATCH 0650/2516] fix broken link (#421) --- src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh | 0 src/doc/rustc-dev-guide/src/appendix/code-index.md | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh diff --git a/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh b/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh old mode 100644 new mode 100755 diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 52a7f42d6f956..267a3a3ea54b7 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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 2c03515c2b8b67c96bbadb640d5009cd9e6542e2 Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Tue, 13 Aug 2019 18:20:22 +0300 Subject: [PATCH 0651/2516] document how to use system llvm --- src/doc/rustc-dev-guide/src/how-to-build-and-run.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 8a803e66cc9d6..2c4d2a979541a 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 f6b723704dcaef4c6ae31ad9313cfe5ac17c45f4 Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Sat, 17 Aug 2019 13:19:10 -0400 Subject: [PATCH 0652/2516] Fix a typo in the implied bounds section of traits/lowering-rules --- src/doc/rustc-dev-guide/src/traits/lowering-rules.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md index bbebf1450a23e..c780e7cf58212 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-rules.md +++ b/src/doc/rustc-dev-guide/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 62aff2d4fee8dd0d835f57a42d3d17074b9cb891 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 21 Aug 2019 10:23:43 -0500 Subject: [PATCH 0653/2516] fix links --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index 19a9217f70a5f..03ba3a41ce206 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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 980894ff92ffa015135f6c8ef3b2b06c4c2538fd Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 24 Aug 2019 21:44:12 -0500 Subject: [PATCH 0654/2516] remove flaky link --- src/doc/rustc-dev-guide/src/traits/bibliography.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/bibliography.md b/src/doc/rustc-dev-guide/src/traits/bibliography.md index b8f345d9d2e86..a0242d4c44b6d 100644 --- a/src/doc/rustc-dev-guide/src/traits/bibliography.md +++ b/src/doc/rustc-dev-guide/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 61d0b1b250033e97253b1cdbbd39789a69dbf29c Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 21 Aug 2019 16:20:09 +0200 Subject: [PATCH 0655/2516] Explain our stability attributes --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/stability.md | 35 ++++++++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/stability.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 75e1fcdc24bb6..cc2696b1f3eb7 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md new file mode 100644 index 0000000000000..34e0db9528f5e --- /dev/null +++ b/src/doc/rustc-dev-guide/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 e17d02d5094bbd174835b2394c11058ba1a7deb8 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 21 Aug 2019 16:32:12 +0200 Subject: [PATCH 0656/2516] Update src/stability.md Co-Authored-By: Jake Goulding --- src/doc/rustc-dev-guide/src/stability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 34e0db9528f5e..42eb7a9a7421d 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 02af3220c72fc0c001d5037e69eced98e7eb6f10 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 21 Aug 2019 17:01:40 +0200 Subject: [PATCH 0657/2516] Apply suggestions from code review Co-Authored-By: Mazdak Farrokhzad --- src/doc/rustc-dev-guide/src/stability.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 42eb7a9a7421d..30f328b7cd47b 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 4a43f0f526bb35fcc3cbe5e16f526b9690a54a1d Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 21 Aug 2019 17:06:05 +0200 Subject: [PATCH 0658/2516] Update stability.md --- src/doc/rustc-dev-guide/src/stability.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 30f328b7cd47b..061ee287156b4 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 821eddd95d2b50111e059d5c9c93e163943a05fe Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 21 Aug 2019 17:31:08 +0200 Subject: [PATCH 0659/2516] Update stability.md --- src/doc/rustc-dev-guide/src/stability.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 061ee287156b4..5af80932f666c 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 a5da4bc253543e3c6e9f5495f8795d2e81032708 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 24 Aug 2019 21:57:17 -0500 Subject: [PATCH 0660/2516] minor fixes --- src/doc/rustc-dev-guide/src/stability.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 5af80932f666c..f35b1c08b99d9 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 534ae0ad9c6c322b6f2bd81f65ef70e5876c0202 Mon Sep 17 00:00:00 2001 From: Wesley Wiser Date: Sun, 25 Aug 2019 12:14:21 -0400 Subject: [PATCH 0661/2516] Improve "Profiling the compiler" docs Add mentions and links to `rustc-perf` and `measureme`. --- src/doc/rustc-dev-guide/src/profiling.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index f6771b07bb00d..b7cc72258c1e0 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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 cbe0ff44d6461a1974a93f033caa92af92a9f7ff Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sun, 25 Aug 2019 10:22:14 +0200 Subject: [PATCH 0662/2516] mention stable-in-unstable issue --- src/doc/rustc-dev-guide/src/stability.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index f35b1c08b99d9..46f62e52037ce 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 b07b83de65518de149c4d3aff6e37a018b7cc626 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Tue, 27 Aug 2019 00:54:11 +0200 Subject: [PATCH 0663/2516] 'or' skipped --- src/doc/rustc-dev-guide/src/borrow_check.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check.md b/src/doc/rustc-dev-guide/src/borrow_check.md index b3eeaa38747bb..76f182083bbfb 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check.md +++ b/src/doc/rustc-dev-guide/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 8da023ab078f0f4992c4e3b45040b96388e7ba90 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Tue, 27 Aug 2019 14:44:07 +0200 Subject: [PATCH 0664/2516] immutable was meant here (#435) --- src/doc/rustc-dev-guide/src/borrow_check.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check.md b/src/doc/rustc-dev-guide/src/borrow_check.md index 76f182083bbfb..b3864aac47cd5 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check.md +++ b/src/doc/rustc-dev-guide/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 45c8e5da0152fa180d95d02dbd737fbc08f61cd8 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Tue, 27 Aug 2019 14:44:58 +0200 Subject: [PATCH 0665/2516] 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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md index 2c4d2a979541a..aac0f211c5c6a 100644 --- a/src/doc/rustc-dev-guide/src/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 c4293b61e76cc67c71eaba085b828496fe08bb25 Mon Sep 17 00:00:00 2001 From: varkor Date: Thu, 1 Aug 2019 00:44:51 +0100 Subject: [PATCH 0666/2516] Update section on "existential type" to "opaque type" --- .../rustc-dev-guide/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/doc/rustc-dev-guide/src/existential-types.md create mode 100644 src/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md diff --git a/src/doc/rustc-dev-guide/src/existential-types.md b/src/doc/rustc-dev-guide/src/existential-types.md deleted file mode 100644 index ef20167c18391..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md b/src/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md new file mode 100644 index 0000000000000..e78d3c75dec80 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 8b129253b820a7371b5029e6466b0b4e1da1e353 Mon Sep 17 00:00:00 2001 From: Edd Barrett Date: Mon, 2 Sep 2019 11:56:43 +0100 Subject: [PATCH 0667/2516] Fix a link in the query docs. --- src/doc/rustc-dev-guide/src/query.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 4ab1d079ec14b..f5961f6ba7669 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 ac968a531545f71915aa9f712f1b1b09199cd0cc Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 5 Sep 2019 16:51:34 -0500 Subject: [PATCH 0668/2516] fix broken link --- src/doc/rustc-dev-guide/src/compiler-team.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index d611376823931..42f6cc0ac0edb 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 ee48f72ba8b8c63c6effff986cfd8017684a0831 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Mon, 26 Aug 2019 18:53:45 +0800 Subject: [PATCH 0669/2516] Updated the mdbook-linkcheck version --- src/doc/rustc-dev-guide/ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index 48df957f97555..a81e21c5616c5 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 0612ebfbf6d4116a2812864dcf9ce5f0f16d1b23 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Tue, 27 Aug 2019 14:21:22 +0800 Subject: [PATCH 0670/2516] Made sure travis caches mdbook-linkcheck's cache file --- src/doc/rustc-dev-guide/.travis.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index bd72a03fc0ba3..8fa2f0c1df1ae 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 6e8f64d25183c05d847ed985664e27068a7aaa5a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 5 Sep 2019 18:58:16 -0500 Subject: [PATCH 0671/2516] hack + drive-by-fix --- src/doc/rustc-dev-guide/.travis.yml | 2 +- src/doc/rustc-dev-guide/book.toml | 4 ++++ src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh | 7 ++++++- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 4 files changed, 12 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 8fa2f0c1df1ae..c33c38b84f21b 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 856ef2eba1341..1d207bf22af9c 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh b/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh index e777f349a3c00..3ec81f6245f39 100755 --- a/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index cc2696b1f3eb7..f672df5101076 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 f3a4f1b44868cf3e911eaf53cd79162bebf9371f Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sun, 8 Sep 2019 07:05:22 +0200 Subject: [PATCH 0672/2516] typo (#441) --- src/doc/rustc-dev-guide/src/codegen/debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/codegen/debugging.md b/src/doc/rustc-dev-guide/src/codegen/debugging.md index 51d5a3b2c35f9..a6ad91dd1a78b 100644 --- a/src/doc/rustc-dev-guide/src/codegen/debugging.md +++ b/src/doc/rustc-dev-guide/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 91ef424d2cd4e407940b13d48cff5a18f91e38ca Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Mon, 16 Sep 2019 09:37:02 -0400 Subject: [PATCH 0673/2516] typo fix (#444) that would get compile to => that would get compiled to --- src/doc/rustc-dev-guide/src/mir/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index 9e9f933fe8183..da221a0d8b10b 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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 d74617f32d23e219629b581af9d4471bb6c28630 Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Mon, 16 Sep 2019 16:34:03 -0400 Subject: [PATCH 0674/2516] 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/doc/rustc-dev-guide/src/mir/construction.md | 2 +- src/doc/rustc-dev-guide/src/mir/passes.md | 2 +- src/doc/rustc-dev-guide/src/test-implementation.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 0e0bf35e7392d..35d68ad73ae20 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/passes.md b/src/doc/rustc-dev-guide/src/mir/passes.md index a0de3ae0e4aa4..b847584b1b5b2 100644 --- a/src/doc/rustc-dev-guide/src/mir/passes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/test-implementation.md b/src/doc/rustc-dev-guide/src/test-implementation.md index 969d6d2e49dbb..59cc7c5bdda87 100644 --- a/src/doc/rustc-dev-guide/src/test-implementation.md +++ b/src/doc/rustc-dev-guide/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 e0de7abe75d50bbf94669d94322844348c1e33b1 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 18 Sep 2019 07:50:39 -0500 Subject: [PATCH 0675/2516] add some instructions to fix toolstate (#446) --- src/doc/rustc-dev-guide/README.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 064f80c6e4d9e..fc9a06a8c20fd 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 89661e0dda9cadb3cf339db8f7a61402152bbb29 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 19 Sep 2019 00:14:59 +0900 Subject: [PATCH 0676/2516] Add guidance for making a PR fixes toolstate --- src/doc/rustc-dev-guide/README.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index fc9a06a8c20fd..42e7e44a4b5f9 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 b15d92d368eac941119831ee5d8d982ea6b8095e Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Fri, 20 Sep 2019 14:08:46 -0500 Subject: [PATCH 0677/2516] 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/doc/rustc-dev-guide/src/codegen/updating-llvm.md b/src/doc/rustc-dev-guide/src/codegen/updating-llvm.md index 50dc949623761..015514bab50a4 100644 --- a/src/doc/rustc-dev-guide/src/codegen/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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 4f5af070ae8901d1fbb2a58fd809630ef652c9c6 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 25 Sep 2019 21:29:26 +0200 Subject: [PATCH 0678/2516] file has since been removed from content (#453) Should of been part of 2ef961e45465a5edfbd3d5c49e4a16cee356b44b --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 - src/doc/rustc-dev-guide/src/diagnostics/json-format.md | 0 2 files changed, 1 deletion(-) delete mode 100644 src/doc/rustc-dev-guide/src/diagnostics/json-format.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index f672df5101076..b5f1bba25970a 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/json-format.md b/src/doc/rustc-dev-guide/src/diagnostics/json-format.md deleted file mode 100644 index e69de29bb2d1d..0000000000000 From e644c6c6008bf45340e41e88965123fa0309df6b Mon Sep 17 00:00:00 2001 From: lzutao Date: Mon, 30 Sep 2019 21:26:27 +0700 Subject: [PATCH 0679/2516] Prefer https in GitHub pages urls (#454) --- .../rustc-dev-guide/src/appendix/bibliography.md | 4 ++-- src/doc/rustc-dev-guide/src/borrow_check.md | 2 +- .../src/borrow_check/region_inference.md | 2 +- src/doc/rustc-dev-guide/src/mir/index.md | 2 +- .../rustc-dev-guide/src/traits/chalk-overview.md | 16 ++++++++-------- src/doc/rustc-dev-guide/src/traits/slg.md | 2 +- 6 files changed, 14 insertions(+), 14 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index 03ba3a41ce206..c3d0446c76b9a 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check.md b/src/doc/rustc-dev-guide/src/borrow_check.md index b3864aac47cd5..0ceb21d72ec9e 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 216128ffb817e..a524fe0f0d610 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index da221a0d8b10b..c02b86e9a15db 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 0a95585f6d718..7eb64804375d4 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/slg.md b/src/doc/rustc-dev-guide/src/traits/slg.md index 948d3fc8ab1bd..6fec79fde959c 100644 --- a/src/doc/rustc-dev-guide/src/traits/slg.md +++ b/src/doc/rustc-dev-guide/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 f2ef7e8199d91214c79c42753d6340c86b8ba6e7 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Tue, 1 Oct 2019 13:39:49 +0200 Subject: [PATCH 0680/2516] issues/issue-12345.rs is an anti-pattern (#456) --- src/doc/rustc-dev-guide/src/tests/adding.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index a660d26b56d1c..8492cbbcc9231 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 1ebb3a2b9e302b836e61fa5609ad21defafea5b1 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Tue, 1 Oct 2019 13:40:58 +0200 Subject: [PATCH 0681/2516] 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/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 6d1327fabb7f6..0051dadcf44ab 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 fe222ef416bf395c8f00a048528b5a1a36523995 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 2 Oct 2019 18:25:14 +0200 Subject: [PATCH 0682/2516] codegen unit is aka CGU (#459) --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 3375d035f72c2..d9867023e0752 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 eb3442eb494b3ccf0b830c8d885613064b9ae2d8 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 2 Oct 2019 18:25:56 +0200 Subject: [PATCH 0683/2516] fix chalk links (#457) * whitespace * update links --- .../rustc-dev-guide/src/macro-expansion.md | 8 ++--- .../src/traits/chalk-overview.md | 34 +++++++++---------- src/doc/rustc-dev-guide/src/traits/slg.md | 14 ++++---- 3 files changed, 28 insertions(+), 28 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index bb429282f4edf..f6a9b3b1f5720 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 7eb64804375d4..a29939919ca35 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/slg.md b/src/doc/rustc-dev-guide/src/traits/slg.md index 6fec79fde959c..74ec89fa0252a 100644 --- a/src/doc/rustc-dev-guide/src/traits/slg.md +++ b/src/doc/rustc-dev-guide/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 140c57b7b409390d43609e681c6f89ec90ccd5bb Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 2 Oct 2019 16:18:28 -0400 Subject: [PATCH 0684/2516] create guide to ICE-breaker groups and specifically advice for LLVM (#452) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 + .../rustc-dev-guide/src/codegen/debugging.md | 46 ++++++++++++++++++- .../rustc-dev-guide/src/ice-breaker/about.md | 37 +++++++++++++++ .../rustc-dev-guide/src/ice-breaker/llvm.md | 31 +++++++++++++ 4 files changed, 115 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/src/ice-breaker/about.md create mode 100644 src/doc/rustc-dev-guide/src/ice-breaker/llvm.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index b5f1bba25970a..b65ba4c746bc1 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen/debugging.md b/src/doc/rustc-dev-guide/src/codegen/debugging.md index a6ad91dd1a78b..1f38c9eee6d29 100644 --- a/src/doc/rustc-dev-guide/src/codegen/debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/ice-breaker/about.md new file mode 100644 index 0000000000000..ab9c667897ed0 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ice-breaker/llvm.md b/src/doc/rustc-dev-guide/src/ice-breaker/llvm.md new file mode 100644 index 0000000000000..e0c90fdafc7da --- /dev/null +++ b/src/doc/rustc-dev-guide/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 343030ec023d327a534b2395f55d9b2867675e19 Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Tue, 1 Oct 2019 21:24:16 -0400 Subject: [PATCH 0685/2516] Removes timeout script so CI does not have false positives --- .../ci/build-ignore-timeouts.sh | 29 ------------------- 1 file changed, 29 deletions(-) delete mode 100755 src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh diff --git a/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh b/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh deleted file mode 100755 index 3ec81f6245f39..0000000000000 --- a/src/doc/rustc-dev-guide/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 6ddf409d8a18f0d670d45659f1f0c3c0d7e2297e Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Tue, 1 Oct 2019 21:28:34 -0400 Subject: [PATCH 0686/2516] Removes timeout script call so CI does not have false pasitives --- src/doc/rustc-dev-guide/.travis.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index c33c38b84f21b..985ed093ffa65 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 ca97497c9e8d0dca1a15c9cac2f905a1109285f5 Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Wed, 2 Oct 2019 11:47:41 -0400 Subject: [PATCH 0687/2516] Revert "Removes timeout script call so CI does not have false pasitives" This reverts commit 5aa733097afa7d4b3ec67e4fb09b76c761f18d17. --- src/doc/rustc-dev-guide/.travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 985ed093ffa65..c33c38b84f21b 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 f40d71327be399c21fa0b8bc72b8a4be96ab3772 Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Wed, 2 Oct 2019 11:48:20 -0400 Subject: [PATCH 0688/2516] 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 src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh diff --git a/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh b/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh new file mode 100755 index 0000000000000..3ec81f6245f39 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 e9abf0071e8e9336fc3cc9bdc0a6c00c15202c9a Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Wed, 2 Oct 2019 15:36:42 -0400 Subject: [PATCH 0689/2516] 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 --- src/doc/rustc-dev-guide/.travis.yml | 2 +- .../ci/build-ignore-timeouts.sh | 29 ------------------- src/doc/rustc-dev-guide/ci/build.sh | 17 +++++++++++ 3 files changed, 18 insertions(+), 30 deletions(-) delete mode 100755 src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh create mode 100755 src/doc/rustc-dev-guide/ci/build.sh diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index c33c38b84f21b..dedec45685aa9 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh b/src/doc/rustc-dev-guide/ci/build-ignore-timeouts.sh deleted file mode 100755 index 3ec81f6245f39..0000000000000 --- a/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/build.sh b/src/doc/rustc-dev-guide/ci/build.sh new file mode 100755 index 0000000000000..b0fae1240b1cc --- /dev/null +++ b/src/doc/rustc-dev-guide/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 3e2d38d34153861f0ae6947e6329307a9afdee03 Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Wed, 2 Oct 2019 18:06:30 -0400 Subject: [PATCH 0690/2516] Fix (build CI script): fails early if linkcheck fails --- src/doc/rustc-dev-guide/ci/build.sh | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/build.sh b/src/doc/rustc-dev-guide/ci/build.sh index b0fae1240b1cc..3954848419d58 100755 --- a/src/doc/rustc-dev-guide/ci/build.sh +++ b/src/doc/rustc-dev-guide/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 96b9ee07587db17e278b46c529bc4fea010e7cda Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Wed, 2 Oct 2019 20:12:26 -0400 Subject: [PATCH 0691/2516] Refactor (build CI script): minimizes the script, thanks to mark-i-m --- src/doc/rustc-dev-guide/ci/build.sh | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/build.sh b/src/doc/rustc-dev-guide/ci/build.sh index 3954848419d58..504957b3f4ef9 100755 --- a/src/doc/rustc-dev-guide/ci/build.sh +++ b/src/doc/rustc-dev-guide/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 f5ba1f3443510892e857fee9c7c25a7d1085aace Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 10 Oct 2019 14:28:49 -0400 Subject: [PATCH 0692/2516] reference the new PR mechanism (#463) * reference the new PR mechanism * wrap lines --- .../rustc-dev-guide/src/ice-breaker/about.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/ice-breaker/about.md index ab9c667897ed0..733011d393a01 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/about.md +++ b/src/doc/rustc-dev-guide/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 80a92c5bd5bbedc80495698d401174609e6236fa Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 9 Oct 2019 09:50:07 -0700 Subject: [PATCH 0693/2516] Expand on stability documentation. --- src/doc/rustc-dev-guide/src/stability.md | 83 ++++++++++++++++++++++-- 1 file changed, 78 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 46f62e52037ce..6b32dff2d5344 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 5f6b2976ee5b42e0bec48bec82c3db475f78ebba Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 10 Oct 2019 14:16:29 -0700 Subject: [PATCH 0694/2516] Try to clarify how crates are able to access force-unstable dependencies without a feature attribute. --- src/doc/rustc-dev-guide/src/stability.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 6b32dff2d5344..1db738cb2f51a 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 1c14f496f17e19f0f62a77afc5ccee25ea0cc3d7 Mon Sep 17 00:00:00 2001 From: Diogo Sousa Date: Sat, 12 Oct 2019 00:20:36 +0100 Subject: [PATCH 0695/2516] Updated kinds that were renamed to generic arguments. This change happened in commit bea3d67c77dd643ef1f89c8bd6562e90b373cec4 on rust-lang/rust. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- .../rustc-dev-guide/src/generic_arguments.md | 50 +++++++++++++++++++ src/doc/rustc-dev-guide/src/kinds.md | 49 ------------------ src/doc/rustc-dev-guide/src/ty.md | 2 +- 4 files changed, 52 insertions(+), 51 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/generic_arguments.md delete mode 100644 src/doc/rustc-dev-guide/src/kinds.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index b65ba4c746bc1..fc866f7b01563 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/generic_arguments.md b/src/doc/rustc-dev-guide/src/generic_arguments.md new file mode 100644 index 0000000000000..c9911acf56412 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/kinds.md b/src/doc/rustc-dev-guide/src/kinds.md deleted file mode 100644 index 194d2ee2ff6c3..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 811f473c9b5a3..6a1cf44446a1c 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 c86863d441715b8b09bfecb392c24cee7944d28d Mon Sep 17 00:00:00 2001 From: Chris Emerson Date: Sat, 12 Oct 2019 23:11:52 +0100 Subject: [PATCH 0696/2516] Fix some paths: tt -> mbe (#465) --- src/doc/rustc-dev-guide/src/macro-expansion.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index f6a9b3b1f5720..01a533ad6cfa5 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 70185c065ce4a8550cad2e5c0e09380a31d7f10e Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Tue, 15 Oct 2019 22:26:17 +0200 Subject: [PATCH 0697/2516] update link --- src/doc/rustc-dev-guide/src/traits/wf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md index 0ced345a151cc..a6981bf4ca81b 100644 --- a/src/doc/rustc-dev-guide/src/traits/wf.md +++ b/src/doc/rustc-dev-guide/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 00a342a2498f6b2d96607454ab74dc4e77752af5 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 17 Oct 2019 09:40:38 +0200 Subject: [PATCH 0698/2516] fix links (#469) --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics.md | 4 ++-- src/doc/rustc-dev-guide/src/implementing_new_features.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 267a3a3ea54b7..d58c4ea1ba7a7 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index f3d51876472ad..0a21c91dcbb24 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 0051dadcf44ab..2958f294a27d4 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 ee64b802c424f8996f2f71d95d8ff585d0e48881 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 18 Oct 2019 02:03:46 +0200 Subject: [PATCH 0699/2516] format examples better (#471) --- .../src/implementing_new_features.md | 28 +++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 2958f294a27d4..3055bf97af853 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 00b5a6ecdeacfaa8df09323ea5a3eff159efbafa Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Tue, 15 Oct 2019 22:13:15 +0200 Subject: [PATCH 0700/2516] I prefers long options in documentation --- src/doc/rustc-dev-guide/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 42e7e44a4b5f9..a5481e82c7fae 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 49f98a9b0f4fea0f2778a222def389037893579c Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 18 Oct 2019 16:22:17 +0900 Subject: [PATCH 0701/2516] Update links (#472) --- src/doc/rustc-dev-guide/src/macro-expansion.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 01a533ad6cfa5..4a0eaeb48d30a 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 2ae9abceac1e66a171320b162b29ecbb09749e83 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 22 Oct 2019 16:11:52 -0400 Subject: [PATCH 0702/2516] 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 --- .../rustc-dev-guide/src/ice-breaker/about.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/ice-breaker/about.md index 733011d393a01..1b59fc23fe85b 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/about.md +++ b/src/doc/rustc-dev-guide/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 9238525e0f14675cf0df06d77891c33948a886dc Mon Sep 17 00:00:00 2001 From: CreepySkeleton Date: Wed, 23 Oct 2019 20:42:52 +0300 Subject: [PATCH 0703/2516] Fix a typo (#477) --- src/doc/rustc-dev-guide/src/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index e2e96fced9fb0..93fcd556a2ded 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 0c155671b2f252d15782eb87f13a8e1204675a92 Mon Sep 17 00:00:00 2001 From: CreepySkeleton Date: Thu, 24 Oct 2019 21:54:40 +0300 Subject: [PATCH 0704/2516] Fix missing link (#480) --- src/doc/rustc-dev-guide/src/ice-breaker/about.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/ice-breaker/about.md index 1b59fc23fe85b..7869bdbce9672 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/about.md +++ b/src/doc/rustc-dev-guide/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 7e990e4d0d21121f7e9e511048ef825c33603c81 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 24 Oct 2019 14:30:01 -0500 Subject: [PATCH 0705/2516] move readme to guide (#481) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/codegen/backend-agnostic.md | 203 ++++++++++++++++++ 2 files changed, 204 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index fc866f7b01563..fdec4ffde40c8 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen/backend-agnostic.md b/src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md new file mode 100644 index 0000000000000..b6436b679a2bd --- /dev/null +++ b/src/doc/rustc-dev-guide/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 fde83900dff98927a0dffd0c396ff50e1a2b2091 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Sun, 27 Oct 2019 20:29:02 +0100 Subject: [PATCH 0706/2516] Explain `rustc_on_unimplemented` --- src/doc/rustc-dev-guide/src/diagnostics.md | 147 +++++++++++++++++++++ 1 file changed, 147 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 0a21c91dcbb24..b096d6a546076 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 8c470a117abb497747acdb5431b7a25e5c9b4d20 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 28 Oct 2019 08:06:57 +0200 Subject: [PATCH 0707/2516] 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/doc/rustc-dev-guide/src/compiler-documenting.md b/src/doc/rustc-dev-guide/src/compiler-documenting.md index 97636fad5b4bb..5c80c3d1c8505 100644 --- a/src/doc/rustc-dev-guide/src/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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 a6a5e541c8989500d2469a00ee3a3b4abe5b496a Mon Sep 17 00:00:00 2001 From: Mark Rousskov Date: Tue, 29 Oct 2019 17:09:10 -0400 Subject: [PATCH 0708/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/diagnostics.md | 51 ++++++--- .../src/diagnostics/lintstore.md | 105 ++++++++++++++++++ 3 files changed, 144 insertions(+), 13 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/diagnostics/lintstore.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index fdec4ffde40c8..770686f01e7e1 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index b096d6a546076..62baa7b60a01f 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md new file mode 100644 index 0000000000000..50538c2b52763 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 5f59fbb864e0b47e39f2213cd4612832e1668517 Mon Sep 17 00:00:00 2001 From: Mark Rousskov Date: Wed, 30 Oct 2019 09:32:16 -0400 Subject: [PATCH 0709/2516] Fixup links in lintstore docs (#487) --- src/doc/rustc-dev-guide/src/diagnostics/lintstore.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index 50538c2b52763..5ce13f96770aa 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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 d7cf62e91b281b623f9cbb565f7a44da1f963560 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Fri, 1 Nov 2019 17:36:47 +0000 Subject: [PATCH 0710/2516] 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 --- .../rustc-dev-guide/src/implementing_new_features.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 3055bf97af853..73a6a40a0b20e 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 2ce38ef2e11c6a8af25606ffbff6e2c8e0788f54 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 0711/2516] Sanitizers implementation in rustc --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/sanitizers.md | 68 +++++++++++++++++++++++ 2 files changed, 69 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/sanitizers.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 770686f01e7e1..453493d9a95b7 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/sanitizers.md b/src/doc/rustc-dev-guide/src/sanitizers.md new file mode 100644 index 0000000000000..6205433e59499 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 a95dccd509f6c7e46b9294a68c603708eac1ec57 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Sun, 27 Oct 2019 23:10:32 +0100 Subject: [PATCH 0712/2516] Please don't rustfmt. --- src/doc/rustc-dev-guide/src/conventions.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 3660f33790829..76933d57411c6 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 4134cd4b044f12e63075d8c8eed4fe0e28ad575c Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 5 Nov 2019 09:20:45 -0800 Subject: [PATCH 0713/2516] Fix some broken fragment links. --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- src/doc/rustc-dev-guide/src/borrow_check/region_inference.md | 2 +- src/doc/rustc-dev-guide/src/tests/intro.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index d9867023e0752..5b0f7cfa2aa2c 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index a524fe0f0d610..5ae0965743ce8 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index c043da42967c2..f818fc240056e 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 eba330a5b1dc1916f44fd91b26fab8b791862731 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 10:51:36 -0600 Subject: [PATCH 0714/2516] add guidelines for future-incompat lints --- src/doc/rustc-dev-guide/src/diagnostics.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 62baa7b60a01f..9cfd5a3e1988f 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 996acad260a3879abf946b79769696962ef09779 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 10:47:16 -0600 Subject: [PATCH 0715/2516] add discussion transcript so we don't lose it --- .../rustc-dev-guide/src/macro-expansion.md | 703 ++++++++++++++++++ 1 file changed, 703 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 4a0eaeb48d30a..d1f74ed8b3ba0 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 05185d2d7be648979ea9c897391932f00c5eaea8 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 11:18:49 -0600 Subject: [PATCH 0716/2516] remove all the hacks, add some improvements --- src/doc/rustc-dev-guide/.travis.yml | 4 ++-- src/doc/rustc-dev-guide/book.toml | 3 ++- src/doc/rustc-dev-guide/ci/build.sh | 10 ---------- src/doc/rustc-dev-guide/ci/install.sh | 4 ++-- 4 files changed, 6 insertions(+), 15 deletions(-) delete mode 100755 src/doc/rustc-dev-guide/ci/build.sh diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index dedec45685aa9..50b7d6b955a6d 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 1d207bf22af9c..b5bced996d0bb 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/build.sh b/src/doc/rustc-dev-guide/ci/build.sh deleted file mode 100755 index 504957b3f4ef9..0000000000000 --- a/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh index a81e21c5616c5..5cb2f41fca976 100755 --- a/src/doc/rustc-dev-guide/ci/install.sh +++ b/src/doc/rustc-dev-guide/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 4b61151de3c67a5c9ce4f001469cd9a0fe34712a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 11:29:51 -0600 Subject: [PATCH 0717/2516] fix broken links --- .../src/borrow_check/moves_and_initialization/move_paths.md | 1 + .../src/borrow_check/region_inference/member_constraints.md | 2 +- src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md | 2 ++ src/doc/rustc-dev-guide/src/variance.md | 2 +- 4 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index 157a9eaf3e8ac..9b8cbd47aedee 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index 7e254f0a25b4e..0435ff8c85051 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen/backend-agnostic.md b/src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md index b6436b679a2bd..3bf1bde83c57e 100644 --- a/src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md index c6a1a320bbfd8..af23330e8a5df 100644 --- a/src/doc/rustc-dev-guide/src/variance.md +++ b/src/doc/rustc-dev-guide/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 4a01cb86fe1a2413196f4e57ffdaa49655d96cd2 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 5 Nov 2019 11:32:44 -0600 Subject: [PATCH 0718/2516] Add travis badge to README --- src/doc/rustc-dev-guide/README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index a5481e82c7fae..12d46b4e528dc 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 599540cf5037d8f4ad93023734f9d790eb6edb66 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sun, 3 Nov 2019 21:50:07 +0100 Subject: [PATCH 0719/2516] expand and update Miri description --- src/doc/rustc-dev-guide/src/miri.md | 107 +++++++++++++++++++++------- 1 file changed, 82 insertions(+), 25 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index aee2376f1b982..77ae8f93d8898 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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 3ea406335b8eb0c3ecd2c60c2b2cfe446d18f229 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Tue, 5 Nov 2019 16:57:35 +0100 Subject: [PATCH 0720/2516] apply linebreaks --- src/doc/rustc-dev-guide/src/miri.md | 159 +++++++++++++++++----------- 1 file changed, 96 insertions(+), 63 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index 77ae8f93d8898..09c31e0a5cee1 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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 e7aa2b0b2c885cd967354dbd083b85675a51c239 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 10:42:53 -0600 Subject: [PATCH 0721/2516] add compiler lecture series appendix --- src/doc/rustc-dev-guide/src/SUMMARY.md | 3 +- .../src/appendix/compiler-lecture.md | 51 +++++++++++++++++++ 2 files changed, 53 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/src/appendix/compiler-lecture.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 453493d9a95b7..99f724614607b 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/compiler-lecture.md b/src/doc/rustc-dev-guide/src/appendix/compiler-lecture.md new file mode 100644 index 0000000000000..3912bab767cae --- /dev/null +++ b/src/doc/rustc-dev-guide/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 b53100901bcbfce96d49455717f0fed128eb087d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 13:35:47 -0600 Subject: [PATCH 0722/2516] fold subchapters --- src/doc/rustc-dev-guide/book.toml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index b5bced996d0bb..82a6b59b03f8b 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 196e0e9864ff3bf23f581c90f866c6578f6da3ac Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 10:27:07 -0600 Subject: [PATCH 0723/2516] breakup the building chapter --- src/doc/rustc-dev-guide/src/SUMMARY.md | 9 +- .../src/building/bootstrapping.md | 161 ++++++ .../build-install-distribution-artifacts.md | 0 .../{ => building}/compiler-documenting.md | 0 src/doc/rustc-dev-guide/src/building/ctags.md | 26 + .../src/building/how-to-build-and-run.md | 277 +++++++++ .../rustc-dev-guide/src/building/suggested.md | 78 +++ .../src/how-to-build-and-run.md | 533 ------------------ 8 files changed, 548 insertions(+), 536 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/building/bootstrapping.md rename src/doc/rustc-dev-guide/src/{ => building}/build-install-distribution-artifacts.md (100%) rename src/doc/rustc-dev-guide/src/{ => building}/compiler-documenting.md (100%) create mode 100644 src/doc/rustc-dev-guide/src/building/ctags.md create mode 100644 src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md create mode 100644 src/doc/rustc-dev-guide/src/building/suggested.md delete mode 100644 src/doc/rustc-dev-guide/src/how-to-build-and-run.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 99f724614607b..b264f8df44106 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md new file mode 100644 index 0000000000000..fd54c80cf4964 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md b/src/doc/rustc-dev-guide/src/building/build-install-distribution-artifacts.md similarity index 100% rename from src/doc/rustc-dev-guide/src/build-install-distribution-artifacts.md rename to src/doc/rustc-dev-guide/src/building/build-install-distribution-artifacts.md diff --git a/src/doc/rustc-dev-guide/src/compiler-documenting.md b/src/doc/rustc-dev-guide/src/building/compiler-documenting.md similarity index 100% rename from src/doc/rustc-dev-guide/src/compiler-documenting.md rename to src/doc/rustc-dev-guide/src/building/compiler-documenting.md diff --git a/src/doc/rustc-dev-guide/src/building/ctags.md b/src/doc/rustc-dev-guide/src/building/ctags.md new file mode 100644 index 0000000000000..9b63314578d01 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md new file mode 100644 index 0000000000000..5142507690933 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md new file mode 100644 index 0000000000000..427a4485847d6 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/how-to-build-and-run.md deleted file mode 100644 index aac0f211c5c6a..0000000000000 --- a/src/doc/rustc-dev-guide/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 caa9caa01772ce50114aeeb6e9142fd7023346dc Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 11:11:45 -0600 Subject: [PATCH 0724/2516] fix links --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- src/doc/rustc-dev-guide/src/building/suggested.md | 2 +- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 5142507690933..5e049e39e3edb 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 427a4485847d6..6b23f2a0d7e9d 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 7582eece5630a..9615e9e2ab36b 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 e43f7e38be0cc48f063e428c5b8935899d983221 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 5 Nov 2019 21:51:45 -0600 Subject: [PATCH 0725/2516] Fix diagram src --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index fd54c80cf4964..12650907724ec 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 59adfcb500166008c6b7a1b02df45a76cb864c2b Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 7 Nov 2019 08:51:31 +0900 Subject: [PATCH 0726/2516] Add link to git repository for book --- src/doc/rustc-dev-guide/book.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 82a6b59b03f8b..94b0e6d8c277b 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 5891e73cf14fa65349142d069c0ea15f57a52bc7 Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Fri, 8 Nov 2019 11:09:45 -0500 Subject: [PATCH 0727/2516] 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/doc/rustc-dev-guide/src/rustc-driver.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 715e6295d4d49..f2ed1bab8efa0 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 08449a62845e337263380ac49adb9fa1419c78d5 Mon Sep 17 00:00:00 2001 From: PotHix Date: Thu, 7 Nov 2019 22:26:47 -0300 Subject: [PATCH 0728/2516] 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/doc/rustc-dev-guide/src/tests/intro.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index f818fc240056e..e78e33475fac7 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 f210bcee18ab07e0cd43b6af61c3032defe89e12 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 8 Nov 2019 00:50:26 +0200 Subject: [PATCH 0729/2516] fix typo --- src/doc/rustc-dev-guide/src/building/suggested.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 6b23f2a0d7e9d..07f834eacd613 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 3e561a3c80c6d93c4ce50612559506bb61eb74a7 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 7 Nov 2019 23:24:38 +0200 Subject: [PATCH 0730/2516] rustc_back has long since been renamed to rustc_target --- src/doc/rustc-dev-guide/src/high-level-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 93b5592c3a563..eedb3e6324564 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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 c314450b99e55852d3f40f7f7f30dd25ce283125 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 7 Nov 2019 23:42:46 +0200 Subject: [PATCH 0731/2516] those are now documented in this guide --- src/doc/rustc-dev-guide/src/high-level-overview.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index eedb3e6324564..6255590344f02 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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 eb26cd56ca8b27a76d3652d9e007b27b6726169e Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 7 Nov 2019 22:10:49 +0200 Subject: [PATCH 0732/2516] whitespace --- .../rustc-dev-guide/src/building/compiler-documenting.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/compiler-documenting.md b/src/doc/rustc-dev-guide/src/building/compiler-documenting.md index 5c80c3d1c8505..345a324bd7ce7 100644 --- a/src/doc/rustc-dev-guide/src/building/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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 36314738f3b221f77d6c6880c87f2a5b0fc91570 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 7 Nov 2019 22:12:50 +0200 Subject: [PATCH 0733/2516] trim down "Document rustc" --- .../src/building/compiler-documenting.md | 24 ++++++------------- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/compiler-documenting.md b/src/doc/rustc-dev-guide/src/building/compiler-documenting.md index 345a324bd7ce7..16df10f72019b 100644 --- a/src/doc/rustc-dev-guide/src/building/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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 26c441e8b0e46ace2f0fc69e6c91801ef2abc0df Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 8 Nov 2019 10:31:12 -0600 Subject: [PATCH 0734/2516] Fix chalk links --- src/doc/rustc-dev-guide/src/traits/chalk-overview.md | 6 +++--- src/doc/rustc-dev-guide/src/traits/wf.md | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index a29939919ca35..0f102d4d04d16 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md index a6981bf4ca81b..aa17f8c2c6ff2 100644 --- a/src/doc/rustc-dev-guide/src/traits/wf.md +++ b/src/doc/rustc-dev-guide/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 1bfdcdbd9eb86dc80b343a703c8a1b10e74a6354 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 11 Nov 2019 10:36:45 -0600 Subject: [PATCH 0735/2516] update parser chapter --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- .../src/appendix/code-index.md | 2 +- .../rustc-dev-guide/src/macro-expansion.md | 3 ++ src/doc/rustc-dev-guide/src/the-parser.md | 48 +++++++++++-------- 4 files changed, 32 insertions(+), 23 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index b264f8df44106..4a63b92828f2f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index d58c4ea1ba7a7..0f423c6a4829b 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index d1f74ed8b3ba0..a3a3ae762319a 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index 5796ae40ec0b0..d089a8418102a 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 391c77b14877458871d168330880b97da69f87bd Mon Sep 17 00:00:00 2001 From: ksqsf Date: Tue, 12 Nov 2019 15:56:04 +0800 Subject: [PATCH 0736/2516] backtraces work on Mac --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 8f3a331aa687e..736de9771283a 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 99ba3e67d6a00b5e0945cf7f7e5fee5504ace6ea Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 13 Nov 2019 09:51:01 -0600 Subject: [PATCH 0737/2516] add compilers biblio (#512) --- .../src/appendix/background.md | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/background.md b/src/doc/rustc-dev-guide/src/appendix/background.md index dbfe6a3dbe826..50a550dc8d09e 100644 --- a/src/doc/rustc-dev-guide/src/appendix/background.md +++ b/src/doc/rustc-dev-guide/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 7ecacb4af5e3de2386a97ad406ab98e73b8881b2 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 12 Nov 2019 10:25:55 -0600 Subject: [PATCH 0738/2516] add something for mir opt --- .../rustc-dev-guide/src/mir/optimizations.md | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index ddafa0c99c394..fb550af4cd77f 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 f583948e83a0fee0f0f850808a0e1785810896ab Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 12 Nov 2019 11:21:50 -0600 Subject: [PATCH 0739/2516] add oli note --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + src/doc/rustc-dev-guide/src/mir/optimizations.md | 6 +++++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 5b0f7cfa2aa2c..d737e037f58ea 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index fb550af4cd77f..cb60af1af86a5 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 13d0eabc63958f7438330c268b478538f047716f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 12 Nov 2019 13:36:12 -0600 Subject: [PATCH 0740/2516] typo Co-Authored-By: Yuki Okushi --- src/doc/rustc-dev-guide/src/mir/optimizations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index cb60af1af86a5..d32f508133a46 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 1fbf3dd9caa39bb5f5f41c87aa095a3acb20b7aa Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 12 Nov 2019 13:36:39 -0600 Subject: [PATCH 0741/2516] typo Co-Authored-By: Yuki Okushi --- src/doc/rustc-dev-guide/src/mir/optimizations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index d32f508133a46..cdbe7b4fa51d4 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 61362746dc0e7a397a3faf672ba226ea93e1eced Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 14 Nov 2019 13:34:35 -0600 Subject: [PATCH 0742/2516] some cleanup --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 -- .../src/implementing_new_features.md | 2 +- src/doc/rustc-dev-guide/src/important-links.md | 16 ---------------- src/doc/rustc-dev-guide/src/tests/running.md | 2 +- 4 files changed, 2 insertions(+), 20 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/important-links.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 4a63b92828f2f..2c29666a0569e 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/src/SUMMARY.md @@ -113,6 +113,4 @@ --- -[](./important-links.md) - [pau]: ./borrow_check/region_inference/placeholders_and_universes.md diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 73a6a40a0b20e..4b2529fff1cdb 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/important-links.md b/src/doc/rustc-dev-guide/src/important-links.md deleted file mode 100644 index 367532519c5e9..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index ef3227f9abe64..af10b85516db0 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 8f1c6763d328b7b2b64c077b3216c5d452c7be04 Mon Sep 17 00:00:00 2001 From: homersimpsons Date: Tue, 19 Nov 2019 23:28:35 +0100 Subject: [PATCH 0743/2516] ty.md: fix a typo --- src/doc/rustc-dev-guide/src/ty.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 6a1cf44446a1c..6295a0db1d176 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 91056aaefa0bbe07bd81229489f8fac37021bfcd Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 20 Nov 2019 10:35:58 -0300 Subject: [PATCH 0744/2516] Minor mir chapter fixes --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- src/doc/rustc-dev-guide/src/mir/optimizations.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index d737e037f58ea..a773e35215375 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index cdbe7b4fa51d4..f3fdd52f3162f 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 ab0640a0530b4e02d3f498f5fa324eb8ffa2c2cc Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 20 Nov 2019 14:37:28 -0600 Subject: [PATCH 0745/2516] -Cllvm-arg is actually -Cllvm-args --- src/doc/rustc-dev-guide/src/codegen/debugging.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/codegen/debugging.md b/src/doc/rustc-dev-guide/src/codegen/debugging.md index 1f38c9eee6d29..4eab306068c27 100644 --- a/src/doc/rustc-dev-guide/src/codegen/debugging.md +++ b/src/doc/rustc-dev-guide/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 dcc452a13c49297502728e4b4a40716768cbea68 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 24 Nov 2019 18:32:18 -0600 Subject: [PATCH 0746/2516] website has disappeared --- src/doc/rustc-dev-guide/src/rustdoc.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 318a8e2e12cd6..072bf31c10677 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 2810d33295998d5b199921c40ffa83d7e395bf82 Mon Sep 17 00:00:00 2001 From: Ivan Tham Date: Mon, 25 Nov 2019 08:14:10 +0800 Subject: [PATCH 0747/2516] Fix typo --- src/doc/rustc-dev-guide/src/diagnostics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 9cfd5a3e1988f..040e7db01bd24 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 14bc65ee13ef9d605ad0a219ba2ffb46a9e57bda Mon Sep 17 00:00:00 2001 From: Hanif Bin Ariffin Date: Thu, 21 Nov 2019 13:52:07 -0500 Subject: [PATCH 0748/2516] 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/doc/rustc-dev-guide/src/diagnostics.md | 10 ++-- src/doc/rustc-dev-guide/src/hir.md | 2 +- .../src/profiling/with_perf.md | 48 +++++++++---------- src/doc/rustc-dev-guide/src/tests/running.md | 24 +++++----- 5 files changed, 52 insertions(+), 52 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 5e049e39e3edb..69c418c28d20d 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 040e7db01bd24..a9a9221ab8cf0 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index b100422701188..0a48d11238e31 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 9615e9e2ab36b..cca2d06d133df 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index af10b85516db0..4a86d2cce8b39 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 5af9a8edc84f71e64c208e5872d4ab4595c895b1 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 26 Nov 2019 17:09:44 -0600 Subject: [PATCH 0749/2516] 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... --- src/doc/rustc-dev-guide/.travis.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 50b7d6b955a6d..6ee759d4ccdd4 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.travis.yml @@ -13,7 +13,6 @@ install: - bash -x ci/install.sh script: - mdbook build -- mdbook test notifications: email: on_success: never From 0d0f1e20df7950356ea398ff3b6d71209e8ed32c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 26 Nov 2019 17:06:43 -0600 Subject: [PATCH 0750/2516] Revert "website has disappeared" This reverts commit 0930e773f1123f9c118f81af3f00b09f1dafc17e. --- src/doc/rustc-dev-guide/src/rustdoc.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 072bf31c10677..318a8e2e12cd6 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 6d62c507cd54b491687010fd2818855dd15bd216 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 26 Nov 2019 17:24:19 -0600 Subject: [PATCH 0751/2516] Define FCP where first used --- src/doc/rustc-dev-guide/src/walkthrough.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 93fcd556a2ded..9c4ba15339387 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 10c7269ac0f21e6e82aaa8f4164076c7be866fd9 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 26 Nov 2019 20:59:34 -0600 Subject: [PATCH 0752/2516] Update src/walkthrough.md Co-Authored-By: Yuki Okushi --- src/doc/rustc-dev-guide/src/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 9c4ba15339387..5d54404efa7ad 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 71d57f5f74f8e3efb0c2cfe3ec55cc1168734ce2 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 27 Nov 2019 11:06:07 -0600 Subject: [PATCH 0753/2516] Add Karrq's salsa chapter (#529) * add Karrq's salsa chapter * add youtu.be short url --- src/doc/rustc-dev-guide/book.toml | 2 +- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/salsa.md | 214 +++++++++++++++++++++++++ 3 files changed, 216 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/src/salsa.md diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 94b0e6d8c277b..bbba6d60ce771 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 2c29666a0569e..fe6584b55437c 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md new file mode 100644 index 0000000000000..b34647ad1e7d5 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 a682d038107e6388d9492aaa44bc8c53f63114e3 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 4 Dec 2019 01:37:34 +0200 Subject: [PATCH 0754/2516] fix links --- src/doc/rustc-dev-guide/src/closure.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index c47ad9bc8a4a8..deeed0722181f 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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 a901945587499a041ce0ef98f435627b1b5cb64e 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 0755/2516] Remove reference to run-pass tests --- src/doc/rustc-dev-guide/src/tests/intro.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index e78e33475fac7..4572d23ca95ba 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 e9c69b21d866afcd07f22bde3947c3485b8170f4 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 6 Dec 2019 17:00:39 +0900 Subject: [PATCH 0756/2516] Fix links --- .../rustc-dev-guide/src/appendix/code-index.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics.md | 17 ++++------------- .../src/diagnostics/lintstore.md | 4 ++-- src/doc/rustc-dev-guide/src/rustc-driver.md | 2 +- 4 files changed, 8 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 0f423c6a4829b..1c8d1d70760dc 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index a9a9221ab8cf0..c6c8f4fbaa73f 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index 5ce13f96770aa..32e6ef8b87c73 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index f2ed1bab8efa0..eb5390a92067e 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 d45703aecaabcafebe1d849899d2d3b941a18dcb Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 6 Dec 2019 11:06:38 -0600 Subject: [PATCH 0757/2516] move the last few things from the forge --- src/doc/rustc-dev-guide/src/SUMMARY.md | 3 + .../rustc-dev-guide/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 +++++++++++++++ .../rustc-dev-guide/src/queries/example-0.png | Bin 0 -> 106577 bytes .../rustc-dev-guide/src/queries/profiling.md | 341 + 7 files changed, 314183 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/bug-fix-procedure.md create mode 100644 src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md create mode 100644 src/doc/rustc-dev-guide/src/queries/example-0.counts.txt create mode 100644 src/doc/rustc-dev-guide/src/queries/example-0.html create mode 100644 src/doc/rustc-dev-guide/src/queries/example-0.png create mode 100644 src/doc/rustc-dev-guide/src/queries/profiling.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index fe6584b55437c..7b334c36c5157 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/bug-fix-procedure.md b/src/doc/rustc-dev-guide/src/bug-fix-procedure.md new file mode 100644 index 0000000000000..0f6d6c973b240 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md new file mode 100644 index 0000000000000..22d9b12c374d0 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/example-0.counts.txt b/src/doc/rustc-dev-guide/src/queries/example-0.counts.txt new file mode 100644 index 0000000000000..e5b9c3f3d80bc --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/example-0.html b/src/doc/rustc-dev-guide/src/queries/example-0.html new file mode 100644 index 0000000000000..b196aaa837391 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/example-0.png b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md new file mode 100644 index 0000000000000..0b574cd0698a2 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 14481656f5777742077bb0df8924cd213600a3c8 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 6 Dec 2019 11:24:22 -0600 Subject: [PATCH 0758/2516] fix link --- src/doc/rustc-dev-guide/src/queries/profiling.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index 0b574cd0698a2..156fd65a91429 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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 35669443eace4d7bea7017b5ee46d2d80cca6c92 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 13 Dec 2019 11:01:05 -0600 Subject: [PATCH 0759/2516] update NLL after refactorings --- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check.md b/src/doc/rustc-dev-guide/src/borrow_check.md index 0ceb21d72ec9e..034c36253e646 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 5ae0965743ce8..84d30bdb47465 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 5f3b29c6d342a..ee86ae1483925 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index 0d5219aa9651e..4086b71ef45b5 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/type_check.md b/src/doc/rustc-dev-guide/src/borrow_check/type_check.md index ee955d971705f..0db895619eb74 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/type_check.md +++ b/src/doc/rustc-dev-guide/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 50c6bc4add2728f11fff74f274ff6587e0780ff7 Mon Sep 17 00:00:00 2001 From: Christoph Schmidler Date: Mon, 16 Dec 2019 10:25:00 +0100 Subject: [PATCH 0760/2516] Correct statement that wrongly claims the json emitter still lives in libsyntax crate --- src/doc/rustc-dev-guide/src/diagnostics.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index c6c8f4fbaa73f..e4fb443c17d93 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 843e23cd5c3a28c721889a724f7274382e86d5df Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 20 Dec 2019 04:28:42 +0200 Subject: [PATCH 0761/2516] salsa: reduce overlong sentence --- src/doc/rustc-dev-guide/src/salsa.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index b34647ad1e7d5..68e92b29fd3d1 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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 bf3597ec12e3e676d92173fe4231a17e918f86b3 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 20 Dec 2019 04:51:08 +0200 Subject: [PATCH 0762/2516] chalk: place brackets in usual positions --- src/doc/rustc-dev-guide/src/traits/chalk-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 0f102d4d04d16..a33cbcc63aec5 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 cd31b973e41aeb56fdc2cc2fa8fd0123200459e7 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 21 Dec 2019 07:00:09 -0600 Subject: [PATCH 0763/2516] Document rustc internal env vars a little bit (#513) --- .../src/building/bootstrapping.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 12650907724ec..5bdc8dc6f18ba 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 4347a2b9f3602bc37323ab17ba65ef3982a45144 Mon Sep 17 00:00:00 2001 From: Ross MacArthur Date: Sun, 22 Dec 2019 17:20:48 +0200 Subject: [PATCH 0764/2516] Rewrap stability.md to column 79 --- src/doc/rustc-dev-guide/src/stability.md | 83 +++++++++++++----------- 1 file changed, 44 insertions(+), 39 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 1db738cb2f51a..86d2a2e693c3d 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 6cf400b75f3b18004ad448d40eceabd82f7764ab Mon Sep 17 00:00:00 2001 From: Ross MacArthur Date: Sun, 22 Dec 2019 17:21:02 +0200 Subject: [PATCH 0765/2516] Update stability documentation, mention `issue = "none"` --- src/doc/rustc-dev-guide/src/stability.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 86d2a2e693c3d..9e75495b1eebe 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 a57693df70e13e20b19b094d7b993f60ddf28536 Mon Sep 17 00:00:00 2001 From: Ross MacArthur Date: Sun, 22 Dec 2019 23:36:34 +0200 Subject: [PATCH 0766/2516] Minor update to stability.md --- src/doc/rustc-dev-guide/src/stability.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 9e75495b1eebe..292d88813a12f 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 11cc47efec1808b2f52daa76bcc7b9ead78d881f Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Tue, 24 Dec 2019 01:16:23 +0100 Subject: [PATCH 0767/2516] Introduce `rustc_const_stable` and explain `rustc_const_unstable` (#542) --- src/doc/rustc-dev-guide/src/stability.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 292d88813a12f..f48c3d529ddf1 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 cf454c3fc2c994175b845aaaabcfa2d21522d2e7 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 26 Dec 2019 13:47:36 +0900 Subject: [PATCH 0768/2516] Update link --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index c3d0446c76b9a..7c27a3ed6237e 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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 9e9fdd9215dba02529a3c708c652e8a51d22bd4e Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 29 Dec 2019 06:44:47 +0900 Subject: [PATCH 0769/2516] Fix link --- src/doc/rustc-dev-guide/src/miri.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index 09c31e0a5cee1..1f11633a733fd 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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 abb4d7d104de900e6032c36f4fa709b59671dfc6 Mon Sep 17 00:00:00 2001 From: YOUNGSUK KIM Date: Sat, 28 Dec 2019 16:26:14 -0500 Subject: [PATCH 0770/2516] minor grammar fixes --- src/doc/rustc-dev-guide/src/codegen.md | 2 +- src/doc/rustc-dev-guide/src/conventions.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/codegen.md b/src/doc/rustc-dev-guide/src/codegen.md index c8d51f31843eb..c7d2fc071a472 100644 --- a/src/doc/rustc-dev-guide/src/codegen.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 76933d57411c6..7f7bf32e211ed 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index e4fb443c17d93..f646d70a2cd5f 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 095a0f3c1702c76de96ff7bd426d789209033848 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 31 Dec 2019 06:46:18 -0600 Subject: [PATCH 0771/2516] add a bit about def path (#548) --- src/doc/rustc-dev-guide/src/hir.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 0a48d11238e31..67becec1210f4 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 c7aee944bbd93e8079faa839b63dac0593bb65da Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 31 Dec 2019 06:46:49 -0600 Subject: [PATCH 0772/2516] More info about using local LLVM (#547) * more info about llvm-config * typo Co-Authored-By: Santiago Pastorino Co-authored-by: Santiago Pastorino --- src/doc/rustc-dev-guide/src/building/suggested.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 07f834eacd613..087e9dee86656 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 66e8c4fd12a67baaab0ce42e27cdec9616c9bec8 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 1 Jan 2020 03:45:01 +0900 Subject: [PATCH 0773/2516] Fix links (#549) --- .../src/appendix/code-index.md | 4 +-- .../src/high-level-overview.md | 2 +- .../rustc-dev-guide/src/macro-expansion.md | 28 +++++++++---------- 3 files changed, 17 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 1c8d1d70760dc..062293f7e26a1 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 6255590344f02..e4b9ff3720cbd 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index a3a3ae762319a..9280fa9bc4757 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 441a9229fdc3e649807ef8a4bbd7648687572b26 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Tue, 29 Oct 2019 18:18:04 -0400 Subject: [PATCH 0774/2516] Add panic implementation docs --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/panic-implementation.md | 105 ++++++++++++++++++ 2 files changed, 106 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/panic-implementation.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 7b334c36c5157..125e20cf6fe17 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md new file mode 100644 index 0000000000000..d8bb4c315ae97 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 33cd0d0c9b0de1e4c4a6d1e1d6e2a8baf7c4ad58 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Mon, 2 Dec 2019 13:06:44 -0500 Subject: [PATCH 0775/2516] Apply some fixes Co-Authored-By: Who? Me?! --- src/doc/rustc-dev-guide/src/panic-implementation.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index d8bb4c315ae97..41338ce0df48f 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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 1b0297fe0e267e68f4f8e391add94e852d468d8d Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Mon, 2 Dec 2019 13:03:27 -0500 Subject: [PATCH 0776/2516] Fix typo --- src/doc/rustc-dev-guide/src/panic-implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index 41338ce0df48f..7de4bc0a2e4ae 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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 bb1f79d856e202f604d8fead4ea493af076ff05d Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Mon, 2 Dec 2019 13:10:02 -0500 Subject: [PATCH 0777/2516] Fix name of lang item --- src/doc/rustc-dev-guide/src/panic-implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index 7de4bc0a2e4ae..4dbc5e613be65 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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 5708a70893c7cd237b48bff0a1980c813c08332b Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Mon, 2 Dec 2019 13:12:06 -0500 Subject: [PATCH 0778/2516] Update for method renames in libstd --- src/doc/rustc-dev-guide/src/panic-implementation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index 4dbc5e613be65..4f4fb1a989138 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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 b73fee53d34af6c5c8448831991f1737531e9752 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Mon, 2 Dec 2019 13:19:19 -0500 Subject: [PATCH 0779/2516] Fix line lengths --- src/doc/rustc-dev-guide/src/panic-implementation.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index 4f4fb1a989138..b62e2643672bc 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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 15b76609ec915e1635466100b63eba94374f91e0 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Thu, 2 Jan 2020 22:32:19 -0500 Subject: [PATCH 0780/2516] Apply fixes Co-Authored-By: Yuki Okushi --- .../src/panic-implementation.md | 23 ++++++++++--------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index b62e2643672bc..4cb4ebb6fe95b 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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 45500840071d75c90fce0d6791193211951cf0a9 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Thu, 2 Jan 2020 22:58:39 -0500 Subject: [PATCH 0781/2516] Add missing hash marks Fixes #550 I can no longer reproduce the issue --- src/doc/rustc-dev-guide/src/panic-implementation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index 4cb4ebb6fe95b..497c81fd0b3c2 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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 1daca67360a6245566a00559ce3c359820baa7da Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 3 Jan 2020 11:12:37 -0300 Subject: [PATCH 0782/2516] 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/doc/rustc-dev-guide/src/ty.md | 683 ++++++++++++++++++++++++++---- 1 file changed, 596 insertions(+), 87 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 6295a0db1d176..c9d2feba9eaca 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 1dd43c3273518a539a1836b26b0363594e218dfb Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 6 Jan 2020 05:47:43 +0900 Subject: [PATCH 0783/2516] Fix links --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 4 ++-- src/doc/rustc-dev-guide/src/diagnostics.md | 6 +++--- src/doc/rustc-dev-guide/src/rustc-driver.md | 2 +- src/doc/rustc-dev-guide/src/the-parser.md | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 062293f7e26a1..67030bee094c3 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index f646d70a2cd5f..0bf869ccdd0cc 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index eb5390a92067e..50c7b2731a24c 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index d089a8418102a..3584d73e4465a 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 690f8240a4aacfb77b6697477279fcdbe3027013 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 9 Jan 2020 03:48:26 +0900 Subject: [PATCH 0784/2516] Fix links and paths --- .../src/appendix/code-index.md | 10 +++--- src/doc/rustc-dev-guide/src/hir.md | 22 ++++++------- src/doc/rustc-dev-guide/src/rustdoc.md | 2 +- src/doc/rustc-dev-guide/src/ty.md | 32 +++++++++---------- 4 files changed, 33 insertions(+), 33 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 67030bee094c3..39e16c1cba0d1 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 67becec1210f4..60a3c3b8bb3d6 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 318a8e2e12cd6..fc964b18e3da2 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index c9d2feba9eaca..870e886d3c1e4 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 67245a2f3085e4a0d725253ab6e2c0120294a995 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 9 Jan 2020 03:55:41 +0900 Subject: [PATCH 0785/2516] Fix line length --- src/doc/rustc-dev-guide/src/ty.md | 35 ++++++++++++++++--------------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 870e886d3c1e4..b665dadf175eb 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 bd659c8bc8637b7f1dcf4a184248df47c884e99e Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 13 Jan 2020 00:17:22 +0900 Subject: [PATCH 0786/2516] Fix links and paths --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 2 +- .../rustc-dev-guide/src/implementing_new_features.md | 7 ++++--- src/doc/rustc-dev-guide/src/stabilization_guide.md | 11 ++++++----- 3 files changed, 11 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index 7c27a3ed6237e..dc06b63f576dc 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 4b2529fff1cdb..ff9a709e6ff8e 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 302be41d0a991..73edc3be5b469 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 6e0c4958d7c2df9a009694dbaebc6f8e08416698 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 14 Jan 2020 02:14:25 +0900 Subject: [PATCH 0787/2516] Fix links --- src/doc/rustc-dev-guide/book.toml | 2 +- src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics/lintstore.md | 2 +- src/doc/rustc-dev-guide/src/mir/construction.md | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index bbba6d60ce771..3a5b1fd6dc7e5 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md b/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md index 09e7fbefe5f68..f036c3a8c50f2 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index 32e6ef8b87c73..b0ae9a328756c 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 35d68ad73ae20..bc0db84f9eb95 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 d2cea2458cb11ee8783052cde539c3621e08afc5 Mon Sep 17 00:00:00 2001 From: jethrogb Date: Mon, 13 Jan 2020 20:06:54 -0800 Subject: [PATCH 0788/2516] Update .gitattributes See https://github.com/rust-lang/rust/pull/57858 --- src/doc/rustc-dev-guide/.gitattributes | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/.gitattributes b/src/doc/rustc-dev-guide/.gitattributes index d56abbf3047f0..fd394480f15c3 100644 --- a/src/doc/rustc-dev-guide/.gitattributes +++ b/src/doc/rustc-dev-guide/.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 5858e90162579e938a5518177d6685993345c71c Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 14 Jan 2020 13:47:41 +0900 Subject: [PATCH 0789/2516] Fix link --- src/doc/rustc-dev-guide/src/mir/construction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index bc0db84f9eb95..52d1f46099a83 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 0affb6e38a0e7a160dd3441673902fb8e9c78bd2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 23 Jan 2020 14:18:51 -0500 Subject: [PATCH 0790/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/ice-breaker/cleanup-crew.md | 114 ++++++++++++++++++ 2 files changed, 115 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/ice-breaker/cleanup-crew.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 125e20cf6fe17..d88d230820d5e 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ice-breaker/cleanup-crew.md b/src/doc/rustc-dev-guide/src/ice-breaker/cleanup-crew.md new file mode 100644 index 0000000000000..436b51fd18853 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 192d6870eeaac94b90176bd868182af2d4a6950e Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 29 Jan 2020 18:11:45 +0100 Subject: [PATCH 0791/2516] Replaced simple comment with doc comment --- src/doc/rustc-dev-guide/src/implementing_new_features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index ff9a709e6ff8e..9fb977761d7d0 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 4658c0f267bf8049d78d1e5b8d909d90e10684f9 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 27 Jan 2020 16:11:01 -0300 Subject: [PATCH 0792/2516] Add an example PR to join the Cleanup Crew ICE-Breakers --- src/doc/rustc-dev-guide/src/ice-breaker/about.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/ice-breaker/about.md index 7869bdbce9672..6a82f7a008143 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/about.md +++ b/src/doc/rustc-dev-guide/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 770fd808667e8b496de34136c24027298794fc3d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 30 Jan 2020 14:01:42 -0600 Subject: [PATCH 0793/2516] use cargo install --- src/doc/rustc-dev-guide/.travis.yml | 3 ++- src/doc/rustc-dev-guide/ci/install.sh | 24 ------------------------ 2 files changed, 2 insertions(+), 25 deletions(-) delete mode 100755 src/doc/rustc-dev-guide/ci/install.sh diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 6ee759d4ccdd4..2c9aa573de820 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/install.sh b/src/doc/rustc-dev-guide/ci/install.sh deleted file mode 100755 index 5cb2f41fca976..0000000000000 --- a/src/doc/rustc-dev-guide/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 aa1af2fe9273d21f3ac4bfe2d6b22d9996368788 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 2 Feb 2020 23:26:13 -0600 Subject: [PATCH 0794/2516] Fix broken links (#570) --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 4 ++-- src/doc/rustc-dev-guide/src/diagnostics.md | 4 ++-- src/doc/rustc-dev-guide/src/hir.md | 2 +- src/doc/rustc-dev-guide/src/implementing_new_features.md | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 39e16c1cba0d1..1b53e64262207 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 0bf869ccdd0cc..e65893cf5ef11 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 60a3c3b8bb3d6..28cc83c58ff6b 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 9fb977761d7d0..27988056d2771 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 7935d37e3663e3c48e9d638e962482be2825c185 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 2 Feb 2020 21:36:49 -0600 Subject: [PATCH 0795/2516] Update README --- src/doc/rustc-dev-guide/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 12d46b4e528dc..c2ac04052a6d9 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 bd287110fadd706fca3f1bd4216474b2f697ee65 Mon Sep 17 00:00:00 2001 From: Wesley Wiser Date: Sun, 2 Feb 2020 21:34:01 -0500 Subject: [PATCH 0796/2516] Add a mention of the new `-Zllvm-time-trace` flag --- src/doc/rustc-dev-guide/src/codegen/debugging.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/codegen/debugging.md b/src/doc/rustc-dev-guide/src/codegen/debugging.md index 4eab306068c27..0da29bfb9e63a 100644 --- a/src/doc/rustc-dev-guide/src/codegen/debugging.md +++ b/src/doc/rustc-dev-guide/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 c0764ae97c0ca336cbd8b799ca6082ded22727c9 Mon Sep 17 00:00:00 2001 From: Eduard-Mihai Burtescu Date: Thu, 6 Feb 2020 00:55:42 +0200 Subject: [PATCH 0797/2516] mir: begin documenting user variable debuginfo. (#571) --- src/doc/rustc-dev-guide/src/mir/index.md | 32 ++++++++++++++++-------- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index c02b86e9a15db..dbc2a316f0ef9 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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 843edfd4a4e2d8e94ce1c942fbaf9e8e71b37e00 Mon Sep 17 00:00:00 2001 From: Felix S Klock II Date: Thu, 6 Feb 2020 14:38:42 -0500 Subject: [PATCH 0798/2516] 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/doc/rustc-dev-guide/src/ice-breaker/about.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/ice-breaker/about.md index 6a82f7a008143..e71001e5bdcd9 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/about.md +++ b/src/doc/rustc-dev-guide/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 61a6004d68dd0db37d782ca5963cba70c5dfa717 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 0799/2516] Update sanitizers documentation (#562) --- src/doc/rustc-dev-guide/src/sanitizers.md | 44 +++++++++++++---------- 1 file changed, 25 insertions(+), 19 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/sanitizers.md b/src/doc/rustc-dev-guide/src/sanitizers.md index 6205433e59499..5e1f396f51fa3 100644 --- a/src/doc/rustc-dev-guide/src/sanitizers.md +++ b/src/doc/rustc-dev-guide/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 060fe72ccd962bc8ddeb89646cf339f3d0b669dd Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Mon, 10 Feb 2020 16:32:36 -0500 Subject: [PATCH 0800/2516] minor typo fix --- src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md b/src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md index 3bf1bde83c57e..cda841b2d0205 100644 --- a/src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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 a482acb19a01f1d3e65ee255f002655af8abb6ae Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Mon, 10 Feb 2020 19:10:41 -0500 Subject: [PATCH 0801/2516] minor typo fix --- src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md b/src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md index cda841b2d0205..0c501a2cc3a20 100644 --- a/src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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 7364a0adb0e12281ffbb4dbb80f40104008c2a2d Mon Sep 17 00:00:00 2001 From: Loris-intergalactique Date: Wed, 12 Feb 2020 17:35:10 +0100 Subject: [PATCH 0802/2516] Minor typo correction --- src/doc/rustc-dev-guide/src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index f5961f6ba7669..aaf083178608c 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 8566559a4611520d95b5f90ad369b1615ada73ad Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Wed, 12 Feb 2020 15:15:44 -0500 Subject: [PATCH 0803/2516] Correction of type name (#576) `ConstraintSet` => `OutlivesConstraintSet` --- .../borrow_check/region_inference/constraint_propagation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index ee86ae1483925..6d190ae1ae3a3 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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 b3f0310eac972a48311698568254df72c4eb6607 Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Fri, 14 Feb 2020 09:56:21 -0500 Subject: [PATCH 0804/2516] Add link to `rustc::mir::Location` (#579) --- src/doc/rustc-dev-guide/src/borrow_check/region_inference.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 84d30bdb47465..d0da861db12e9 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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 d0887d5dad0b071a1bd7c8c3015b9328458ded13 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 15 Feb 2020 07:01:35 +0900 Subject: [PATCH 0805/2516] Fix link --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 9280fa9bc4757..0c7a7a2e3456a 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 8c9d8893d0be174fc7d54a30b10081efcc743c88 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 0806/2516] Add links to the rustc docs (#578) --- src/doc/rustc-dev-guide/src/query.md | 50 +++++++++++++++++----------- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index aaf083178608c..9ae6baa9e6a3d 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 c401f8f8556fdcc17fc9296c00a65a04da988568 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 15 Feb 2020 07:45:22 +0900 Subject: [PATCH 0807/2516] Update section following current state --- src/doc/rustc-dev-guide/src/macro-expansion.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 0c7a7a2e3456a..bc3b9dc5ce615 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 8dc7002acd3faf6505e23dc6cc3f939e15488bbd Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 18 Feb 2020 14:45:02 -0600 Subject: [PATCH 0808/2516] fix link --- src/doc/rustc-dev-guide/src/traits/hrtb.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/hrtb.md b/src/doc/rustc-dev-guide/src/traits/hrtb.md index 8b3a9f649bd00..f41d43ffd35fd 100644 --- a/src/doc/rustc-dev-guide/src/traits/hrtb.md +++ b/src/doc/rustc-dev-guide/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 043e1aaf771d3352ccf7035234800d01729bd436 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 19 Feb 2020 07:31:20 -0600 Subject: [PATCH 0809/2516] spit of type folder and generics subchapters (#586) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 + src/doc/rustc-dev-guide/src/generics.md | 144 ++++++++++++++ src/doc/rustc-dev-guide/src/ty-fold.md | 105 ++++++++++ src/doc/rustc-dev-guide/src/ty.md | 248 ------------------------ 4 files changed, 251 insertions(+), 248 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/generics.md create mode 100644 src/doc/rustc-dev-guide/src/ty-fold.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index d88d230820d5e..56adee7e9a643 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/generics.md b/src/doc/rustc-dev-guide/src/generics.md new file mode 100644 index 0000000000000..310b9cda694da --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty-fold.md b/src/doc/rustc-dev-guide/src/ty-fold.md new file mode 100644 index 0000000000000..e144767dcbe73 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index b665dadf175eb..9fc34527bf3c9 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 6b6e7282f2f70c2525ad80909bad4f55cb166bc3 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 18 Feb 2020 11:36:57 -0600 Subject: [PATCH 0810/2516] document ./x.py fmt --- src/doc/rustc-dev-guide/src/tests/intro.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 4572d23ca95ba..eb8aec8008476 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 76be6d1f2f34d195719d374a0062366cfe5755b1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 20 Feb 2020 09:57:51 -0600 Subject: [PATCH 0811/2516] tidy runs rustfmt check --- src/doc/rustc-dev-guide/src/tests/intro.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index eb8aec8008476..e5b7fcacc3b65 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 d7dd369ae036abe2b5caa471afe9108f34f2674c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 20 Feb 2020 10:23:14 -0600 Subject: [PATCH 0812/2516] mention tidy bless --- src/doc/rustc-dev-guide/src/tests/intro.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index e5b7fcacc3b65..6691f2d4e24bf 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 a67b4c05a3ed058a18a175376bdb2b927074788c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 18 Feb 2020 11:16:42 -0600 Subject: [PATCH 0813/2516] create a separate chapter on arenas/interning --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/memory.md | 88 +++++++++++++ src/doc/rustc-dev-guide/src/rustc-driver.md | 13 -- src/doc/rustc-dev-guide/src/ty.md | 117 +++++------------- src/doc/rustc-dev-guide/src/type-inference.md | 7 -- 5 files changed, 119 insertions(+), 107 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/memory.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 56adee7e9a643..ae1ea0b2e04d0 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/memory.md b/src/doc/rustc-dev-guide/src/memory.md new file mode 100644 index 0000000000000..bfec4fe1984c4 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 50c7b2731a24c..e240ea58b2263 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 9fc34527bf3c9..bb2c24b13b2cf 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index d4734525f75b3..a0ae13384fc78 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 59fd3331a67d8e83f6143de352391fb5ba3db1df Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 18 Feb 2020 11:19:17 -0600 Subject: [PATCH 0814/2516] update glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index a773e35215375..fbd76f25d2f61 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 5110fc2ea233f95b6e8040ea4947e008dc4b8a6c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 20 Feb 2020 09:55:33 -0600 Subject: [PATCH 0815/2516] add back link --- src/doc/rustc-dev-guide/src/type-inference.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index a0ae13384fc78..dca93dbdf3f48 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 9c864111332a205c1f837a3a350680e1cf19b9e8 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 25 Feb 2020 07:05:37 +0100 Subject: [PATCH 0816/2516] Name resolution: Add intro section --- .../rustc-dev-guide/src/name-resolution.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 3117217e5e35e..c7bf5d11136ec 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 7808e6e1d8678fbea44dbcdf97f954e6818fbe6d Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 25 Feb 2020 07:05:55 +0100 Subject: [PATCH 0817/2516] typo: eg. -> e.g. --- src/doc/rustc-dev-guide/src/name-resolution.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index c7bf5d11136ec..3507d4d8845f9 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 20f098c6165e8333f3301dc83550e434c9ec3ef8 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 25 Feb 2020 07:48:13 +0100 Subject: [PATCH 0818/2516] Don't reference librustc_resolve just yet. It's mentioned further down with more details. --- src/doc/rustc-dev-guide/src/name-resolution.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 3507d4d8845f9..50820d97e670b 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 fc249196445cb28796d74e379f6a740a74f1c8d8 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 0819/2516] 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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index a1fbed2e54813..83c1275509857 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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 0f835fbd8d0157abd4235ea376b7ddc8722e13d1 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 27 Feb 2020 14:22:15 +0900 Subject: [PATCH 0820/2516] Move bless section to running chapter --- src/doc/rustc-dev-guide/src/tests/adding.md | 19 ++----------------- src/doc/rustc-dev-guide/src/tests/running.md | 14 ++++++++++++++ 2 files changed, 16 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 8492cbbcc9231..d8cf8e8841c19 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 4a86d2cce8b39..f5d8cbdbd03a5 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 fde440dc16b4ba7b844b3bbe2af733d7a5336869 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sun, 1 Mar 2020 23:19:30 +0100 Subject: [PATCH 0821/2516] Make all links in Appendix E active --- .../src/appendix/compiler-lecture.md | 70 ++++++------------- 1 file changed, 23 insertions(+), 47 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/compiler-lecture.md b/src/doc/rustc-dev-guide/src/appendix/compiler-lecture.md index 3912bab767cae..bbeb52aa3a018 100644 --- a/src/doc/rustc-dev-guide/src/appendix/compiler-lecture.md +++ b/src/doc/rustc-dev-guide/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 646e5af0d04c02fa6a526c0f93e69de9c45a84ae Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Mon, 2 Mar 2020 20:41:41 +0100 Subject: [PATCH 0822/2516] 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 +++---- .../rustc-dev-guide/src/appendix/glossary.md | 2 +- .../src/appendix/stupid-stats.md | 4 +-- .../rustc-dev-guide/src/bug-fix-procedure.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics.md | 6 ++-- .../src/high-level-overview.md | 6 ++-- src/doc/rustc-dev-guide/src/hir.md | 2 +- .../rustc-dev-guide/src/macro-expansion.md | 28 +++++++++---------- .../rustc-dev-guide/src/name-resolution.md | 2 +- .../src/test-implementation.md | 14 +++++----- src/doc/rustc-dev-guide/src/the-parser.md | 12 ++++---- 11 files changed, 44 insertions(+), 44 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 1b53e64262207..0321da195df38 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index fbd76f25d2f61..f5274a8fc6d7d 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md index 6ed7d1cbd9662..ea9b6e0f063a1 100644 --- a/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/bug-fix-procedure.md b/src/doc/rustc-dev-guide/src/bug-fix-procedure.md index 0f6d6c973b240..90d8fb48b6125 100644 --- a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index e65893cf5ef11..c112f3471d8a5 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index e4b9ff3720cbd..76f4bc9553de4 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 28cc83c58ff6b..2c3e44a72ba63 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index bc3b9dc5ce615..eb9800c6522ca 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 50820d97e670b..6dfbd91a86c23 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/test-implementation.md b/src/doc/rustc-dev-guide/src/test-implementation.md index 59cc7c5bdda87..e5bcedf13626e 100644 --- a/src/doc/rustc-dev-guide/src/test-implementation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index 3584d73e4465a..8b8ef77cd76b2 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 a7219f193c890b27e30767999b5d35ad785fae7c Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Mon, 2 Mar 2020 22:00:05 +0100 Subject: [PATCH 0823/2516] =?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 --- src/doc/rustc-dev-guide/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index c2ac04052a6d9..a0cd760a2dad5 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/README.md @@ -82,4 +82,4 @@ git commit -m "Update rustc-guide" 12. Wait for PR to merge -Voila! +Voilà! From abbcba34f067e5404d4639dfc4542219e33a5171 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 3 Mar 2020 10:41:36 -0600 Subject: [PATCH 0824/2516] typo (#599) --- src/doc/rustc-dev-guide/src/tests/adding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index d8cf8e8841c19..dadd8e2c15fdb 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 6d502e853195b31c596cbaee53febcb7a5fa2cda Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 8 Mar 2020 00:24:56 +0900 Subject: [PATCH 0825/2516] Remove references to chalkify tests (#604) --- .../src/traits/lowering-module.md | 25 ++++++------------- 1 file changed, 8 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md index 3f1515ef8afb0..3c5bd7be5d54e 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-module.md +++ b/src/doc/rustc-dev-guide/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 5012ac80c99bf3243c2fe50af1687bc8fd17d48e Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 7 Mar 2020 20:05:26 -0600 Subject: [PATCH 0826/2516] Just lol (#603) * Just lol * Update src/appendix/humorust.md Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/appendix/humorust.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md index ef926c1c69eae..8bd9c48a6c4d7 100644 --- a/src/doc/rustc-dev-guide/src/appendix/humorust.md +++ b/src/doc/rustc-dev-guide/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 1b4cca3083ce914123d44a92d138c12e62f40f3e Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 9 Mar 2020 16:10:52 -0500 Subject: [PATCH 0827/2516] cname (#606) --- src/doc/rustc-dev-guide/CNAME | 1 + 1 file changed, 1 insertion(+) create mode 100644 src/doc/rustc-dev-guide/CNAME diff --git a/src/doc/rustc-dev-guide/CNAME b/src/doc/rustc-dev-guide/CNAME new file mode 100644 index 0000000000000..a59cd86cd4ef2 --- /dev/null +++ b/src/doc/rustc-dev-guide/CNAME @@ -0,0 +1 @@ +rustc-dev-guide.rust-lang.org From 62757a5b263b2b4e3c4a86ffe6b2875eb26aeafe Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Mon, 9 Mar 2020 23:02:24 -0400 Subject: [PATCH 0828/2516] Update ./x.py tidy testing documentation (#607) * update all docs to use ./x.py test tidy syntax --- src/doc/rustc-dev-guide/src/conventions.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md | 2 +- src/doc/rustc-dev-guide/src/tests/intro.md | 4 ++-- src/doc/rustc-dev-guide/src/tests/running.md | 6 +++--- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 7f7bf32e211ed..303eedd4ee864 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md index 22d9b12c374d0..0e923c5e1bae1 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 6691f2d4e24bf..6a528ae4571c3 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index f5d8cbdbd03a5..f5c9bdb721ee2 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 5dd0fa1e7b7f707dd730c91b7b0aa99aa19ed4fd Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 10 Mar 2020 22:02:55 +0900 Subject: [PATCH 0829/2516] Add travis config for custom domain (#608) --- src/doc/rustc-dev-guide/.travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 2c9aa573de820..e88ae40b2a83a 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 25ccfc7b740536f80d2dd98805a3dd1237a02b2e Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 10 Mar 2020 11:01:43 -0300 Subject: [PATCH 0830/2516] 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 --- src/doc/rustc-dev-guide/README.md | 20 +++++++++---------- src/doc/rustc-dev-guide/book.toml | 2 +- .../rustc-dev-guide/src/about-this-guide.md | 2 +- .../src/debugging-support-in-rustc.md | 6 +++--- .../rustc-dev-guide/src/ice-breaker/llvm.md | 2 +- .../src/implementing_new_features.md | 4 ++-- .../rustc-dev-guide/src/macro-expansion.md | 6 +++--- .../rustc-dev-guide/src/mir/optimizations.md | 10 +++++----- src/doc/rustc-dev-guide/src/part-1-intro.md | 2 +- src/doc/rustc-dev-guide/src/part-2-intro.md | 2 +- .../src/traits/chalk-overview.md | 2 +- 11 files changed, 29 insertions(+), 29 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index a0cd760a2dad5..098971862376a 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 3a5b1fd6dc7e5..3d90479cb2e7f 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 48ea4dce63514..0519099b3191b 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/debugging-support-in-rustc.md b/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md index 3d08cc8253a23..a11edba7851e8 100644 --- a/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ice-breaker/llvm.md b/src/doc/rustc-dev-guide/src/ice-breaker/llvm.md index e0c90fdafc7da..8a8ef411b4c98 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 27988056d2771..780950c71c8d8 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index eb9800c6522ca..db58733ad1d02 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index f3fdd52f3162f..03dc2195367d1 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-1-intro.md b/src/doc/rustc-dev-guide/src/part-1-intro.md index 65cb1ae482d09..7597c71285ced 100644 --- a/src/doc/rustc-dev-guide/src/part-1-intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-2-intro.md b/src/doc/rustc-dev-guide/src/part-2-intro.md index 6dd26f44cc126..1a47f21e536ea 100644 --- a/src/doc/rustc-dev-guide/src/part-2-intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index a33cbcc63aec5..88ae7b5a23269 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 546bc0c7f05b22f0bcc4602a7f157990914fabc9 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 7 Mar 2020 14:58:39 -0600 Subject: [PATCH 0831/2516] skeleton for backend chapters --- src/doc/rustc-dev-guide/src/SUMMARY.md | 17 ++++++++++------- .../{codegen => backend}/backend-agnostic.md | 0 src/doc/rustc-dev-guide/src/backend/backend.md | 1 + .../src/{ => backend}/codegen.md | 2 +- .../src/{codegen => backend}/debugging.md | 2 +- .../rustc-dev-guide/src/backend/lowering-mir.md | 0 .../rustc-dev-guide/src/backend/monomorph.md | 1 + .../src/{codegen => backend}/updating-llvm.md | 0 .../rustc-dev-guide/src/compiler-debugging.md | 5 ++--- src/doc/rustc-dev-guide/src/ice-breaker/llvm.md | 2 +- 10 files changed, 17 insertions(+), 13 deletions(-) rename src/doc/rustc-dev-guide/src/{codegen => backend}/backend-agnostic.md (100%) create mode 100644 src/doc/rustc-dev-guide/src/backend/backend.md rename src/doc/rustc-dev-guide/src/{ => backend}/codegen.md (98%) rename src/doc/rustc-dev-guide/src/{codegen => backend}/debugging.md (99%) create mode 100644 src/doc/rustc-dev-guide/src/backend/lowering-mir.md create mode 100644 src/doc/rustc-dev-guide/src/backend/monomorph.md rename src/doc/rustc-dev-guide/src/{codegen => backend}/updating-llvm.md (100%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index ae1ea0b2e04d0..7cc41e0b62c7f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen/backend-agnostic.md b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md similarity index 100% rename from src/doc/rustc-dev-guide/src/codegen/backend-agnostic.md rename to src/doc/rustc-dev-guide/src/backend/backend-agnostic.md diff --git a/src/doc/rustc-dev-guide/src/backend/backend.md b/src/doc/rustc-dev-guide/src/backend/backend.md new file mode 100644 index 0000000000000..167391a88b37d --- /dev/null +++ b/src/doc/rustc-dev-guide/src/backend/backend.md @@ -0,0 +1 @@ +# The Compiler Backend diff --git a/src/doc/rustc-dev-guide/src/codegen.md b/src/doc/rustc-dev-guide/src/backend/codegen.md similarity index 98% rename from src/doc/rustc-dev-guide/src/codegen.md rename to src/doc/rustc-dev-guide/src/backend/codegen.md index c7d2fc071a472..02bb4d573a65d 100644 --- a/src/doc/rustc-dev-guide/src/codegen.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen/debugging.md b/src/doc/rustc-dev-guide/src/backend/debugging.md similarity index 99% rename from src/doc/rustc-dev-guide/src/codegen/debugging.md rename to src/doc/rustc-dev-guide/src/backend/debugging.md index 0da29bfb9e63a..06e62d9ec0eee 100644 --- a/src/doc/rustc-dev-guide/src/codegen/debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/lowering-mir.md b/src/doc/rustc-dev-guide/src/backend/lowering-mir.md new file mode 100644 index 0000000000000..e69de29bb2d1d diff --git a/src/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md new file mode 100644 index 0000000000000..fc54886f9f3ca --- /dev/null +++ b/src/doc/rustc-dev-guide/src/backend/monomorph.md @@ -0,0 +1 @@ +# Monomorphization diff --git a/src/doc/rustc-dev-guide/src/codegen/updating-llvm.md b/src/doc/rustc-dev-guide/src/backend/updating-llvm.md similarity index 100% rename from src/doc/rustc-dev-guide/src/codegen/updating-llvm.md rename to src/doc/rustc-dev-guide/src/backend/updating-llvm.md diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 736de9771283a..08e9417b36ec8 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ice-breaker/llvm.md b/src/doc/rustc-dev-guide/src/ice-breaker/llvm.md index 8a8ef411b4c98..a6291a8c2ea82 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/llvm.md +++ b/src/doc/rustc-dev-guide/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 53da1c15ace472418ee479cee5e08a82fef383be Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 7 Mar 2020 15:10:13 -0600 Subject: [PATCH 0832/2516] add some placeholder text, short intro --- src/doc/rustc-dev-guide/src/backend/backend.md | 16 ++++++++++++++++ .../rustc-dev-guide/src/backend/lowering-mir.md | 3 +++ src/doc/rustc-dev-guide/src/backend/monomorph.md | 7 +++++++ 3 files changed, 26 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/backend/backend.md b/src/doc/rustc-dev-guide/src/backend/backend.md index 167391a88b37d..cc477b3e29484 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/lowering-mir.md b/src/doc/rustc-dev-guide/src/backend/lowering-mir.md index e69de29bb2d1d..e3c1379568ddf 100644 --- a/src/doc/rustc-dev-guide/src/backend/lowering-mir.md +++ b/src/doc/rustc-dev-guide/src/backend/lowering-mir.md @@ -0,0 +1,3 @@ +# Lowering MIR to a Codegen IR + +TODO diff --git a/src/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index fc54886f9f3ca..eaf37f2e1de9b 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/src/backend/monomorph.md @@ -1 +1,8 @@ # Monomorphization + +TODO + + +## Polymorphization + +TODO From af80e82732eb5f082c03909c195c7f6014433e6d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 7 Mar 2020 15:47:35 -0600 Subject: [PATCH 0833/2516] monomorphization chapter --- .../rustc-dev-guide/src/appendix/glossary.md | 3 +- .../rustc-dev-guide/src/backend/monomorph.md | 80 ++++++++++++++++++- 2 files changed, 80 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index f5274a8fc6d7d..715928d21ced1 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index eaf37f2e1de9b..e28eac8f7dbeb 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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 3137ebb2c4da414a12d4c4997cfe1cc0ea2eb013 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 7 Mar 2020 17:26:30 -0600 Subject: [PATCH 0834/2516] update backend chapters from nagisa's notes --- .../rustc-dev-guide/src/appendix/glossary.md | 2 +- .../rustc-dev-guide/src/backend/backend.md | 49 +++++++++++--- .../rustc-dev-guide/src/backend/codegen.md | 66 ++++++++++++------- .../src/backend/lowering-mir.md | 57 +++++++++++++++- .../rustc-dev-guide/src/backend/monomorph.md | 9 +++ 5 files changed, 151 insertions(+), 32 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 715928d21ced1..0218d1a85cc54 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/backend.md b/src/doc/rustc-dev-guide/src/backend/backend.md index cc477b3e29484..9832abb1d779c 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/codegen.md b/src/doc/rustc-dev-guide/src/backend/codegen.md index 02bb4d573a65d..8b005525dc8fc 100644 --- a/src/doc/rustc-dev-guide/src/backend/codegen.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/lowering-mir.md b/src/doc/rustc-dev-guide/src/backend/lowering-mir.md index e3c1379568ddf..42536b9553b13 100644 --- a/src/doc/rustc-dev-guide/src/backend/lowering-mir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index e28eac8f7dbeb..0d2de4d2d0070 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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 c15fc13edf1eed2a8e81e5e508a33fca935b8784 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 8 Mar 2020 21:19:44 -0500 Subject: [PATCH 0835/2516] Update src/backend/codegen.md Co-Authored-By: Yuki Okushi --- src/doc/rustc-dev-guide/src/backend/codegen.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/backend/codegen.md b/src/doc/rustc-dev-guide/src/backend/codegen.md index 8b005525dc8fc..5e277fc3c6072 100644 --- a/src/doc/rustc-dev-guide/src/backend/codegen.md +++ b/src/doc/rustc-dev-guide/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 551b1892bf8f6269b5692e77ed7a815a05cf32b2 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 8 Mar 2020 21:21:33 -0500 Subject: [PATCH 0836/2516] Use common (American) spellings Co-Authored-By: Yuki Okushi --- src/doc/rustc-dev-guide/src/backend/codegen.md | 8 ++++---- src/doc/rustc-dev-guide/src/backend/lowering-mir.md | 6 +++--- src/doc/rustc-dev-guide/src/backend/monomorph.md | 8 ++++---- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/codegen.md b/src/doc/rustc-dev-guide/src/backend/codegen.md index 5e277fc3c6072..d7bad9cfbbaa9 100644 --- a/src/doc/rustc-dev-guide/src/backend/codegen.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/lowering-mir.md b/src/doc/rustc-dev-guide/src/backend/lowering-mir.md index 42536b9553b13..ccc09bee681ab 100644 --- a/src/doc/rustc-dev-guide/src/backend/lowering-mir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index 0d2de4d2d0070..5ea8ba4f0f46c 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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 aff0052b92f895888c03684712e957c4975e9983 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 8 Mar 2020 21:24:38 -0500 Subject: [PATCH 0837/2516] Fix sentence grammar --- src/doc/rustc-dev-guide/src/backend/lowering-mir.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/lowering-mir.md b/src/doc/rustc-dev-guide/src/backend/lowering-mir.md index ccc09bee681ab..93516c5d87f18 100644 --- a/src/doc/rustc-dev-guide/src/backend/lowering-mir.md +++ b/src/doc/rustc-dev-guide/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 e00d4d7c214a6d9118b5b72f2bd9ce956533a762 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 16 Mar 2020 02:37:54 +0900 Subject: [PATCH 0838/2516] Fix broken link --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index dc06b63f576dc..613ee1f4d28b3 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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 f9e29e5f5ae51fe0263063c53e3976f8444a9e20 Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Tue, 18 Feb 2020 23:42:08 -0500 Subject: [PATCH 0839/2516] Clarify sentence meaning --- src/doc/rustc-dev-guide/src/mir/optimizations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index 03dc2195367d1..2af3d06ce334d 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 b65c53fb6971c4382b36615635d7be460aa58982 Mon Sep 17 00:00:00 2001 From: DillionMango Date: Mon, 16 Mar 2020 16:43:48 +0800 Subject: [PATCH 0840/2516] 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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 69c418c28d20d..dbe1f4c7ae4b2 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 97bbb58a262ab5514cb4e6759b5311f79f2df8e5 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 16 Mar 2020 18:20:38 -0500 Subject: [PATCH 0841/2516] Fix broken link (#612) --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index 613ee1f4d28b3..ff09a26b0d4e1 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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 a88f0fd9d67f4abb09a7cb7600783e4b1bd74144 Mon Sep 17 00:00:00 2001 From: Solomon Ucko Date: Mon, 16 Mar 2020 21:54:15 -0400 Subject: [PATCH 0842/2516] Change Rust Koans link to point to first koan --- src/doc/rustc-dev-guide/src/appendix/humorust.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md index 8bd9c48a6c4d7..20a3d1ff18ae6 100644 --- a/src/doc/rustc-dev-guide/src/appendix/humorust.md +++ b/src/doc/rustc-dev-guide/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 d7e691732c301a4d4bae436f29fa0db6e642a8fb Mon Sep 17 00:00:00 2001 From: Solomon Ucko Date: Mon, 16 Mar 2020 22:17:46 -0400 Subject: [PATCH 0843/2516] Changed rustc-ty link to go to first message --- src/doc/rustc-dev-guide/src/appendix/humorust.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md index 20a3d1ff18ae6..3bbedf5bb2e40 100644 --- a/src/doc/rustc-dev-guide/src/appendix/humorust.md +++ b/src/doc/rustc-dev-guide/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 fa8342f428eca91adec9a66af5238f153fb3429a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 17 Mar 2020 06:11:37 -0500 Subject: [PATCH 0844/2516] 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/doc/rustc-dev-guide/src/param_env.md | 59 ++++++++++++++++++++---- 1 file changed, 49 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/param_env.md b/src/doc/rustc-dev-guide/src/param_env.md index 2474886efea6e..9ca117b3122dc 100644 --- a/src/doc/rustc-dev-guide/src/param_env.md +++ b/src/doc/rustc-dev-guide/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 470299d0b35915bdb6f9c4b1e1ae4302ebbbbde7 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 13 Feb 2020 16:03:46 -0300 Subject: [PATCH 0845/2516] Rephrase where compiletest is located --- src/doc/rustc-dev-guide/src/tests/intro.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 6a528ae4571c3..e0ccfdb44fead 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 c991aa4bfb69038674bf4913be0e0b7158b4cdd9 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 13 Feb 2020 16:04:28 -0300 Subject: [PATCH 0846/2516] Avoid as of this writing given that everything is as of this writing :) --- src/doc/rustc-dev-guide/src/tests/intro.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index e0ccfdb44fead..cdb22a19cf42e 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 d0ea44fdbcfc7276a6772b5e8685e05241f2eded Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 14 Feb 2020 09:50:03 -0300 Subject: [PATCH 0847/2516] This is no longer true since rust#49219 --- src/doc/rustc-dev-guide/src/tests/running.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index f5c9bdb721ee2..4126341aad1ff 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 dcc88b93f35c6ec9ec0aade2312284624dce3635 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 17 Feb 2020 12:24:57 -0300 Subject: [PATCH 0848/2516] Suites are defined in enum Mode --- src/doc/rustc-dev-guide/src/compiletest.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 1b424e1a24b4d..8d6386d992a33 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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 ce46c24c0c0701277bd33dd270c394a3fcaffad5 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 17 Feb 2020 12:28:10 -0300 Subject: [PATCH 0849/2516] All the text is at the time of this writing --- src/doc/rustc-dev-guide/src/compiletest.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 8d6386d992a33..dbd6c4b6e1859 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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 5f9b355df629cd90d8073b22433c8e239bec58fe Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 17 Feb 2020 16:58:21 -0300 Subject: [PATCH 0850/2516] It may Take a lot of time instead of 2 hours --- src/doc/rustc-dev-guide/src/walkthrough.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 5d54404efa7ad..226391e6e8519 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 8f2f724eb3988606850c2e6670bd63ac94d4dd57 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 18 Feb 2020 12:32:14 -0300 Subject: [PATCH 0851/2516] This page is diagnostics.html now --- src/doc/rustc-dev-guide/src/bug-fix-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md b/src/doc/rustc-dev-guide/src/bug-fix-procedure.md index 90d8fb48b6125..9ad57be99e9ec 100644 --- a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md +++ b/src/doc/rustc-dev-guide/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 ef26d795e769a63f32d5f5f2837fcad7f684ac13 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 18 Feb 2020 14:47:39 -0300 Subject: [PATCH 0852/2516] Remove typo --- src/doc/rustc-dev-guide/src/implementing_new_features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 780950c71c8d8..686c9b27044cf 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 49c1f9830eba2da1ee7894ee49f859c093a1a5c5 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 16 Mar 2020 18:51:29 -0300 Subject: [PATCH 0853/2516] Fix line lengths --- src/doc/rustc-dev-guide/src/bug-fix-procedure.md | 14 +++++++------- src/doc/rustc-dev-guide/src/tests/intro.md | 10 +++++----- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md b/src/doc/rustc-dev-guide/src/bug-fix-procedure.md index 9ad57be99e9ec..9c711ae1c8749 100644 --- a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index cdb22a19cf42e..b70a23a6a76a3 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 25a734b2dc8d5527818d8da131c19bd3cd7e3bd3 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 16 Mar 2020 18:53:03 -0300 Subject: [PATCH 0854/2516] use-jemalloc -> jemalloc --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index cca2d06d133df..d22a3cf4bca47 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 9786fc514e5ba2c6a1b16412ab3975e43867d30e Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 17 Mar 2020 13:54:42 -0300 Subject: [PATCH 0855/2516] Update src/bug-fix-procedure.md Co-Authored-By: Who? Me?! --- src/doc/rustc-dev-guide/src/bug-fix-procedure.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md b/src/doc/rustc-dev-guide/src/bug-fix-procedure.md index 9c711ae1c8749..55bc8685929d7 100644 --- a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md +++ b/src/doc/rustc-dev-guide/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 299f11c2c0c4d58c8876367cecaeaf9621f8e190 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 17 Mar 2020 13:54:53 -0300 Subject: [PATCH 0856/2516] Update src/walkthrough.md Co-Authored-By: Who? Me?! --- src/doc/rustc-dev-guide/src/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 226391e6e8519..c74f72cc571bf 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 e9c48f2bb9f2ca30878f7da2dd0a18edd121ee19 Mon Sep 17 00:00:00 2001 From: bjorn3 Date: Tue, 17 Mar 2020 20:14:48 +0100 Subject: [PATCH 0857/2516] Fix typo (#618) --- src/doc/rustc-dev-guide/src/backend/backend.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/backend/backend.md b/src/doc/rustc-dev-guide/src/backend/backend.md index 9832abb1d779c..0eaa720361e78 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend.md +++ b/src/doc/rustc-dev-guide/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 ccefce6ccf2d404230518342d1719708f55671c1 Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Thu, 19 Mar 2020 19:57:12 +0100 Subject: [PATCH 0858/2516] words (#622) --- src/doc/rustc-dev-guide/src/ty.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index bb2c24b13b2cf..a4274bc9f552d 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 73a86501a4f33cf1f9b45fc0c5e31cd72904d162 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 20 Mar 2020 11:32:33 -0500 Subject: [PATCH 0859/2516] Move GenericArgs chapter under ty (#624) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 7cc41e0b62c7f..75a77d0aee5b1 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 ebc31a1f5f51215cfaa601eaeccba2c0f83e2d9d Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 21 Mar 2020 16:26:04 -0700 Subject: [PATCH 0860/2516] 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 src/doc/rustc-dev-guide/examples/rustc-driver-example.rs diff --git a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs new file mode 100644 index 0000000000000..3c483e7766351 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 92717a204776ef6882ba7c59d07e9ae5c57f13e9 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 21 Mar 2020 17:18:41 -0700 Subject: [PATCH 0861/2516] Reference example from #621 --- src/doc/rustc-dev-guide/src/rustc-driver.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index e240ea58b2263..2f8f68ebb6bc1 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 6a8d531f6776dead2d52d15f31d949f960ae2b6e Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 21 Mar 2020 17:43:46 -0700 Subject: [PATCH 0862/2516] Fix reference Co-Authored-By: Who? Me?! --- src/doc/rustc-dev-guide/src/rustc-driver.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 2f8f68ebb6bc1..b50ee5b473fbd 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 6e9fd16039eddb426f04bea99fb03b235bd60c5e Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sun, 22 Mar 2020 09:47:26 -0700 Subject: [PATCH 0863/2516] run_compiler is exported by rustc_interface --- src/doc/rustc-dev-guide/examples/rustc-driver-example.rs | 5 ++--- src/doc/rustc-dev-guide/src/rustc-driver.md | 4 ++-- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs index 3c483e7766351..62c80b4aedb80 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index b50ee5b473fbd..90a88b3d630d8 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 74425d5eafdfd8e12d1703dc605cfe339bc97f06 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 22 Mar 2020 18:43:02 -0400 Subject: [PATCH 0864/2516] [stupid-stats] replace removed rustc_codegen_utils with rustc_codegen_ssa --- src/doc/rustc-dev-guide/src/appendix/stupid-stats.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md index ea9b6e0f063a1..7453f4424bb00 100644 --- a/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md +++ b/src/doc/rustc-dev-guide/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 2917e2ff23ec0c150898acb19b2d4ee0de21043d Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 22 Mar 2020 18:24:40 -0400 Subject: [PATCH 0865/2516] add rust-lang/rust license documentation --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/licenses.md | 5 +++++ 2 files changed, 6 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/licenses.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 75a77d0aee5b1..722bcedc6c8a3 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/licenses.md b/src/doc/rustc-dev-guide/src/licenses.md new file mode 100644 index 0000000000000..2d282704da992 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 b0bd9f1eaa5cc8d18f4dad2130676380b2a80917 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 22 Mar 2020 19:34:32 -0400 Subject: [PATCH 0866/2516] Update src/licenses.md Co-Authored-By: Who? Me?! --- src/doc/rustc-dev-guide/src/licenses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/licenses.md b/src/doc/rustc-dev-guide/src/licenses.md index 2d282704da992..e5f9e91bc33a0 100644 --- a/src/doc/rustc-dev-guide/src/licenses.md +++ b/src/doc/rustc-dev-guide/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 44348018cc31c7fa684ceb609bed51908fbb4f31 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 22 Mar 2020 19:34:55 -0400 Subject: [PATCH 0867/2516] change title Co-Authored-By: Who? Me?! --- src/doc/rustc-dev-guide/src/licenses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/licenses.md b/src/doc/rustc-dev-guide/src/licenses.md index e5f9e91bc33a0..b7f17ed9ea82e 100644 --- a/src/doc/rustc-dev-guide/src/licenses.md +++ b/src/doc/rustc-dev-guide/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 a624e9dfb74dba30a3f9189df3c57778cdeef21a Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 22 Mar 2020 19:36:53 -0400 Subject: [PATCH 0868/2516] minor grammar edit --- src/doc/rustc-dev-guide/src/licenses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/licenses.md b/src/doc/rustc-dev-guide/src/licenses.md index b7f17ed9ea82e..06cd8ae6bb9bd 100644 --- a/src/doc/rustc-dev-guide/src/licenses.md +++ b/src/doc/rustc-dev-guide/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 4e4af8f2e063581e3a422bb9c252fb931a242024 Mon Sep 17 00:00:00 2001 From: Alex Aktsipetrov Date: Wed, 25 Mar 2020 20:14:48 +0100 Subject: [PATCH 0869/2516] Update high-level-overview.md Remove an obsolete clarification about libsyntax and co. --- src/doc/rustc-dev-guide/src/high-level-overview.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 76f4bc9553de4..276ff8bc19b3e 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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 7f21fd4d6acc83a7b782b1fa6f60f29f16c5be6c Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Thu, 26 Mar 2020 17:22:46 +0100 Subject: [PATCH 0870/2516] 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/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index fbe226e90c0f6..505dde1a8c562 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index 83c1275509857..5e94f2f03e819 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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 00ae5528a9d3e5370899a5e6e7ed2e0d407169c3 Mon Sep 17 00:00:00 2001 From: Alex Aktsipetrov Date: Fri, 27 Mar 2020 11:42:53 +0100 Subject: [PATCH 0871/2516] 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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index 5e94f2f03e819..2d4214ef36938 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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 0caf3351c1a9c46c7bc61ada0d373c59ebf931b4 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sat, 28 Mar 2020 21:29:57 +0200 Subject: [PATCH 0872/2516] glossary: misc improvements (#638) --- .../rustc-dev-guide/src/appendix/glossary.md | 138 +++++++++--------- 1 file changed, 69 insertions(+), 69 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 0218d1a85cc54..9b208b8c00258 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 1f25205652649b33ab8f5590703b629ac30d38d0 Mon Sep 17 00:00:00 2001 From: ecstatic-morse Date: Sat, 28 Mar 2020 21:23:19 -0700 Subject: [PATCH 0873/2516] 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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index 9b8cbd47aedee..9bc714649aa96 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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 130e15a12a93f89de0705d8b363c3d84c96b588f Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Mon, 30 Mar 2020 14:04:25 +0200 Subject: [PATCH 0874/2516] Rename `librustc` to `librustc_middle` --- src/doc/rustc-dev-guide/README.md | 2 +- .../rustc-dev-guide/src/about-this-guide.md | 2 +- .../src/appendix/code-index.md | 12 +++--- .../rustc-dev-guide/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 +-- .../rustc-dev-guide/src/bug-fix-procedure.md | 8 ++-- .../src/building/compiler-documenting.md | 2 +- src/doc/rustc-dev-guide/src/closure.md | 14 +++---- .../rustc-dev-guide/src/compiler-debugging.md | 10 ++--- src/doc/rustc-dev-guide/src/diagnostics.md | 4 +- src/doc/rustc-dev-guide/src/generics.md | 10 ++--- .../src/high-level-overview.md | 2 +- src/doc/rustc-dev-guide/src/hir.md | 20 +++++----- src/doc/rustc-dev-guide/src/lowering.md | 2 +- .../rustc-dev-guide/src/macro-expansion.md | 2 +- src/doc/rustc-dev-guide/src/memory.md | 12 +++--- src/doc/rustc-dev-guide/src/mir/index.md | 8 ++-- src/doc/rustc-dev-guide/src/mir/visitor.md | 4 +- src/doc/rustc-dev-guide/src/miri.md | 12 +++--- .../src/panic-implementation.md | 4 +- src/doc/rustc-dev-guide/src/param_env.md | 6 +-- .../incremental-compilation-in-detail.md | 2 +- .../src/queries/incremental-compilation.md | 4 +- .../rustc-dev-guide/src/queries/profiling.md | 2 +- src/doc/rustc-dev-guide/src/query.md | 14 +++---- src/doc/rustc-dev-guide/src/rustc-driver.md | 2 +- .../src/traits/associated-types.md | 4 +- .../src/traits/goals-and-clauses.md | 4 +- src/doc/rustc-dev-guide/src/ty-fold.md | 14 +++---- src/doc/rustc-dev-guide/src/ty.md | 38 +++++++++---------- 33 files changed, 123 insertions(+), 123 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 098971862376a..4a8c975fbc1ce 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 0519099b3191b..0882c40c06ad0 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 0321da195df38..a4b18ecc071bd 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 9b208b8c00258..39913a3f7cee0 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index 9bc714649aa96..2c7c73038de10 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index d0da861db12e9..3b844b97c19eb 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index 4086b71ef45b5..9d6b229ef3b2c 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md b/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md index f036c3a8c50f2..ad17bbb66db69 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/bug-fix-procedure.md b/src/doc/rustc-dev-guide/src/bug-fix-procedure.md index 55bc8685929d7..e29ad26e0666f 100644 --- a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/compiler-documenting.md b/src/doc/rustc-dev-guide/src/building/compiler-documenting.md index 16df10f72019b..68c9fd2279f55 100644 --- a/src/doc/rustc-dev-guide/src/building/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index deeed0722181f..d4f9fc3852b1f 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 08e9417b36ec8..9358e0c1599a4 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index c112f3471d8a5..4810e4fa63ddc 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/generics.md b/src/doc/rustc-dev-guide/src/generics.md index 310b9cda694da..cdbf63b9307ee 100644 --- a/src/doc/rustc-dev-guide/src/generics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/high-level-overview.md index 276ff8bc19b3e..472d1ea03b834 100644 --- a/src/doc/rustc-dev-guide/src/high-level-overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 2c3e44a72ba63..8b6637ebedcfe 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/lowering.md b/src/doc/rustc-dev-guide/src/lowering.md index c3a1a96ccf2ae..e0dc99bab0ae8 100644 --- a/src/doc/rustc-dev-guide/src/lowering.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index db58733ad1d02..279598270551d 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/memory.md b/src/doc/rustc-dev-guide/src/memory.md index bfec4fe1984c4..533d1337e2fcc 100644 --- a/src/doc/rustc-dev-guide/src/memory.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index dbc2a316f0ef9..99396903ccff6 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/visitor.md b/src/doc/rustc-dev-guide/src/mir/visitor.md index a5e8e9a0b6135..a0d38ca0b660b 100644 --- a/src/doc/rustc-dev-guide/src/mir/visitor.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index 1f11633a733fd..16f2a18f2bba1 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index 497c81fd0b3c2..549a9cd05f117 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/param_env.md b/src/doc/rustc-dev-guide/src/param_env.md index 9ca117b3122dc..aa6d6e2155c15 100644 --- a/src/doc/rustc-dev-guide/src/param_env.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index 505dde1a8c562..a41becfd0eecc 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/incremental-compilation.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md index bed21f115cb57..be8580f2db099 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index 156fd65a91429..37b1bc97b4fb0 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 9ae6baa9e6a3d..5a739dca985d2 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 90a88b3d630d8..6a2e87f4df682 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/associated-types.md b/src/doc/rustc-dev-guide/src/traits/associated-types.md index d35fb71e171d0..41ce5ac9e897b 100644 --- a/src/doc/rustc-dev-guide/src/traits/associated-types.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index a653528f4cdef..5aba1c20f265a 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty-fold.md b/src/doc/rustc-dev-guide/src/ty-fold.md index e144767dcbe73..f769ee638c240 100644 --- a/src/doc/rustc-dev-guide/src/ty-fold.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index a4274bc9f552d..f8b15632be30f 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 40c37244cf7fed407c66cd1d3551e85df204e113 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 30 Mar 2020 17:45:31 +0200 Subject: [PATCH 0875/2516] QueryDescription has moved --- src/doc/rustc-dev-guide/src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 5a739dca985d2..e008cb628e5ee 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 2b2286711a797ec981abbb73d5e5f1c9ff94ed95 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 31 Mar 2020 15:20:55 -0500 Subject: [PATCH 0876/2516] fix a few more links --- src/doc/rustc-dev-guide/src/bug-fix-procedure.md | 10 ++++++---- src/doc/rustc-dev-guide/src/memory.md | 2 +- src/doc/rustc-dev-guide/src/ty-fold.md | 6 +++--- 3 files changed, 10 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md b/src/doc/rustc-dev-guide/src/bug-fix-procedure.md index e29ad26e0666f..b4159097c0cd8 100644 --- a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/memory.md b/src/doc/rustc-dev-guide/src/memory.md index 533d1337e2fcc..620b7d858e98b 100644 --- a/src/doc/rustc-dev-guide/src/memory.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty-fold.md b/src/doc/rustc-dev-guide/src/ty-fold.md index f769ee638c240..5b409e8ecab79 100644 --- a/src/doc/rustc-dev-guide/src/ty-fold.md +++ b/src/doc/rustc-dev-guide/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 2115680571d8240a2d74900ed47f5149a4b1b0d4 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 31 Mar 2020 15:30:27 -0500 Subject: [PATCH 0877/2516] and a few more links --- src/doc/rustc-dev-guide/src/appendix/stupid-stats.md | 6 +++--- src/doc/rustc-dev-guide/src/compiler-team.md | 5 ++--- src/doc/rustc-dev-guide/src/tests/intro.md | 2 +- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md index 7453f4424bb00..a07956f0fb299 100644 --- a/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index 42f6cc0ac0edb..3f3719f3df109 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index b70a23a6a76a3..b47a9fdee56d0 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 566ac3ecd52f95ff7ad633faaa2a02a10a8303df Mon Sep 17 00:00:00 2001 From: Adam Perry Date: Tue, 14 Jan 2020 21:38:29 -0800 Subject: [PATCH 0878/2516] Implicit Caller Location section. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/codegen/implicit-caller-location.md | 280 ++++++++++++++++++ 2 files changed, 281 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 722bcedc6c8a3..b0bf1966d13ed 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md b/src/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md new file mode 100644 index 0000000000000..4cb3f583ddde9 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 7f93af321c86b00b86efe603805ec432919eb170 Mon Sep 17 00:00:00 2001 From: Adam Perry Date: Tue, 31 Mar 2020 19:21:37 -0700 Subject: [PATCH 0879/2516] fix broken links --- .../src/codegen/implicit-caller-location.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md b/src/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md index 4cb3f583ddde9..5f11dad30b3bb 100644 --- a/src/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md +++ b/src/doc/rustc-dev-guide/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 1d47b1273d1ef4407827cbafa1688db378a7afda Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 30 Mar 2020 18:55:36 +0200 Subject: [PATCH 0880/2516] point to new Cranelift home --- src/doc/rustc-dev-guide/src/backend/backend-agnostic.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md index 0c501a2cc3a20..209df0afa3bc0 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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 18e56c6a904cfe8b64b57c4c664d1e9d367114e4 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 30 Mar 2020 15:43:31 +0200 Subject: [PATCH 0881/2516] follow 4-space indent idiom --- .../src/test-implementation.md | 33 ++++++++++--------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/test-implementation.md b/src/doc/rustc-dev-guide/src/test-implementation.md index e5bcedf13626e..cffc62ceca953 100644 --- a/src/doc/rustc-dev-guide/src/test-implementation.md +++ b/src/doc/rustc-dev-guide/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 bebaeaab763a56c17d7f9dfe9b3d5977c03938de Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 30 Mar 2020 15:42:09 +0200 Subject: [PATCH 0882/2516] it is rustc_parse, not rustc_parser --- src/doc/rustc-dev-guide/src/the-parser.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index 8b8ef77cd76b2..c84ac4ea2e168 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 22ee98a04a732dc92f8b61fb90e3fa578dd2d4e8 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 1 Apr 2020 10:52:31 +0200 Subject: [PATCH 0883/2516] add some type inference links, and fix/improve some stuff (#654) --- src/doc/rustc-dev-guide/src/type-inference.md | 24 ++++++++++++------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index dca93dbdf3f48..9c548364d4c5d 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 f1fa8cbde0835612997d4f3640ba7a94035e91ec Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 1 Apr 2020 10:57:35 +0200 Subject: [PATCH 0884/2516] add link for Resolver::resolve_crate (#653) --- src/doc/rustc-dev-guide/src/name-resolution.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 6dfbd91a86c23..431a8f1d3fd57 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 3521fb90b72ab90a25369eae636e97dd6dd67e28 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 1 Apr 2020 11:04:45 +0200 Subject: [PATCH 0885/2516] Resolver trait moved (#652) --- src/doc/rustc-dev-guide/src/name-resolution.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 431a8f1d3fd57..f3aacba001706 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 f0d9200105da6a0275cc293cd8585669216faaba Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 1 Apr 2020 11:25:14 -0300 Subject: [PATCH 0886/2516] Remove left overs from HackMD migration (#655) --- src/doc/rustc-dev-guide/src/ty.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index f8b15632be30f..76e71584fd5fe 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 9255b60054d9d35c3af5541936981f6c834556c6 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 28 Mar 2020 14:32:09 -0700 Subject: [PATCH 0887/2516] How to get the type of an expression using rustc_interface --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../rustc-driver-interacting-with-the-ast.md | 41 +++++++++++++++++++ 2 files changed, 42 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index b0bf1966d13ed..1a0c9e9e4ef7f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md b/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md new file mode 100644 index 0000000000000..faf0f15146628 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 6efc6bf7f9404700e6211cd99ebba061dac671b4 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Wed, 1 Apr 2020 10:53:26 -0700 Subject: [PATCH 0888/2516] 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/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md b/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md index faf0f15146628..51d5cb6d30f82 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md +++ b/src/doc/rustc-dev-guide/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 dbc55da42d3345c6135e034851b920189595b049 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Wed, 1 Apr 2020 17:10:58 -0700 Subject: [PATCH 0889/2516] Update src/SUMMARY.md Co-Authored-By: Who? Me?! --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 1a0c9e9e4ef7f..e7cb6ed6049aa 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 d3b6c9397624c456eea86dea86e0701f686c6856 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 1 Apr 2020 20:07:00 -0500 Subject: [PATCH 0890/2516] Shorten line --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index e7cb6ed6049aa..d8e6f852fed98 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 568d6dc28fadf11087cbc2c4d0feb60f5d67ac9e Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 2 Apr 2020 13:40:15 -0300 Subject: [PATCH 0891/2516] Update some projects locations (#658) --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 4 ++-- src/doc/rustc-dev-guide/src/conventions.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- src/doc/rustc-dev-guide/src/profiling.md | 2 +- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 8 ++++---- src/doc/rustc-dev-guide/src/tests/intro.md | 2 +- src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md | 2 +- 7 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 9358e0c1599a4..89a763c41f5f4 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 303eedd4ee864..3f957cc27b341 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 4810e4fa63ddc..50da15c220d98 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index b7cc72258c1e0..8eaa8e94f1e6f 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index d22a3cf4bca47..7a4c972f20829 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index b47a9fdee56d0..a81255decf512 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index 5aba1c20f265a..ecd2ce1456b9d 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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 62ef95760ac3b0ccc6f58b31e94831415abbc45a Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Fri, 3 Apr 2020 13:22:08 -0400 Subject: [PATCH 0892/2516] Add BodyId to glossary, and links for ids to HIR identifiers section (#660) --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 39913a3f7cee0..20c35e0acbfa2 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 e93f50cf0d5002c0c59e4c8d4ee22d0afef824ac Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sat, 4 Apr 2020 09:37:39 +0200 Subject: [PATCH 0893/2516] 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/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md b/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md index 51d5cb6d30f82..1749c9db4131a 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md +++ b/src/doc/rustc-dev-guide/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 dac975fa6df8e426b101930f4ef3855cbab46b6b Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Fri, 3 Apr 2020 17:53:37 -0400 Subject: [PATCH 0894/2516] [README.md] add build instructions, link check config instructions, link check error documentation --- src/doc/rustc-dev-guide/README.md | 68 ++++++++++++++++++++++++++++--- 1 file changed, 62 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 4a8c975fbc1ce..a6658b023b627 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 e7920f4fe07191ff549786cc67e615efa66b37df Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 4 Apr 2020 13:24:30 -0500 Subject: [PATCH 0895/2516] Update .gitignore --- src/doc/rustc-dev-guide/.gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/.gitignore b/src/doc/rustc-dev-guide/.gitignore index 7585238efedfc..b8cb34883f587 100644 --- a/src/doc/rustc-dev-guide/.gitignore +++ b/src/doc/rustc-dev-guide/.gitignore @@ -1 +1,4 @@ book + +# prevent accidentally changes +book.toml From 01e9626b36bb5ca6c3f3c41769517e6b31a82692 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sat, 4 Apr 2020 20:15:51 +0200 Subject: [PATCH 0896/2516] remove stupid-stats, and some references to removed API --- src/doc/rustc-dev-guide/src/SUMMARY.md | 11 +- .../src/appendix/stupid-stats.md | 417 ------------------ src/doc/rustc-dev-guide/src/rustc-driver.md | 13 +- 3 files changed, 10 insertions(+), 431 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/appendix/stupid-stats.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index d8e6f852fed98..366146185b602 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/stupid-stats.md b/src/doc/rustc-dev-guide/src/appendix/stupid-stats.md deleted file mode 100644 index a07956f0fb299..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 6a2e87f4df682..2cffba42c878e 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 ec045377ca95046c60e36c3328c6fd9c0037285b Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Fri, 3 Apr 2020 18:04:24 -0400 Subject: [PATCH 0897/2516] Add ids to all glossary items, make existing glossary links point to glossary, add links for def id in query.md --- .../rustc-dev-guide/src/appendix/glossary.md | 158 +++++++++--------- .../rustc-dev-guide/src/backend/monomorph.md | 2 +- src/doc/rustc-dev-guide/src/borrow_check.md | 4 +- .../constraint_propagation.md | 2 +- .../rustc-dev-guide/src/building/suggested.md | 2 +- src/doc/rustc-dev-guide/src/mir/index.md | 2 +- .../rustc-dev-guide/src/mir/optimizations.md | 4 +- src/doc/rustc-dev-guide/src/query.md | 3 +- src/doc/rustc-dev-guide/src/traits/hrtb.md | 2 +- 9 files changed, 90 insertions(+), 89 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 20c35e0acbfa2..4d0f8499967e7 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index 5ea8ba4f0f46c..5e5d2e0c492c5 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check.md b/src/doc/rustc-dev-guide/src/borrow_check.md index 034c36253e646..eea56e1c37a40 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 6d190ae1ae3a3..1389628c89fb8 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 087e9dee86656..e9b48a7efd916 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index 99396903ccff6..85c5d755e9445 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index 2af3d06ce334d..3c143d5557671 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index e008cb628e5ee..6e2193bd3463e 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/hrtb.md b/src/doc/rustc-dev-guide/src/traits/hrtb.md index f41d43ffd35fd..81391f7ae28e2 100644 --- a/src/doc/rustc-dev-guide/src/traits/hrtb.md +++ b/src/doc/rustc-dev-guide/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 a28c76128608727fa28ce8ff58bbe1d473fe7cd1 Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Fri, 3 Apr 2020 18:18:32 -0400 Subject: [PATCH 0898/2516] Wrap link in borrow_check.md to satify line length checks --- src/doc/rustc-dev-guide/src/borrow_check.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check.md b/src/doc/rustc-dev-guide/src/borrow_check.md index eea56e1c37a40..7e076edf37f9a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check.md +++ b/src/doc/rustc-dev-guide/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 ad12d952732f15e7a8e2c60cb945e76e43d5f744 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Tue, 24 Mar 2020 14:52:53 +0100 Subject: [PATCH 0899/2516] Change ICE-breaker ping to use the aliases Related to rust-lang/rust#69949 --- src/doc/rustc-dev-guide/src/ice-breaker/about.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/ice-breaker/about.md index e71001e5bdcd9..60182a3c2bf65 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/about.md +++ b/src/doc/rustc-dev-guide/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 b871e5251a910c044abf5ede013686c17ce17491 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 25 Mar 2020 14:17:52 +0100 Subject: [PATCH 0900/2516] Note that the invocation now are aliases --- src/doc/rustc-dev-guide/src/ice-breaker/about.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/ice-breaker/about.md index 60182a3c2bf65..1e5dc94163ce5 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/about.md +++ b/src/doc/rustc-dev-guide/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 eca7cdac86da5b0b262444de1f9460b93c388e42 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sun, 5 Apr 2020 12:38:05 +0200 Subject: [PATCH 0901/2516] Rework commit message --- src/doc/rustc-dev-guide/src/ice-breaker/about.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/ice-breaker/about.md index 1e5dc94163ce5..642fbe4a1d9c3 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/about.md +++ b/src/doc/rustc-dev-guide/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 025d6d035fdb31eecb2d722592bca31e880a78c1 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 5 Apr 2020 18:02:35 -0500 Subject: [PATCH 0902/2516] update to mdbook 0.3.5 --- src/doc/rustc-dev-guide/.travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index e88ae40b2a83a..df48ef6dfa333 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 a4bcfa13efa8c4d8760fdfe5f1c348f936406bd2 Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Mon, 6 Apr 2020 09:49:21 -0400 Subject: [PATCH 0903/2516] Remove duplicate trait reference entry from glossary, fix alphabetical sorting --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 4d0f8499967e7..11ddb494f3912 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 44d380d4d943d0bdbc4df4ec7128334f26b2b2a2 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 6 Apr 2020 11:23:34 -0500 Subject: [PATCH 0904/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 68 +++++++++++-------- .../rustc-dev-guide/src/about-this-guide.md | 31 ++++++--- src/doc/rustc-dev-guide/src/ast-validation.md | 6 ++ ...high-level-overview.md => compiler-src.md} | 0 .../rustc-dev-guide/src/feature-gate-ck.md | 3 + .../rustc-dev-guide/src/mir/construction.md | 2 +- src/doc/rustc-dev-guide/src/overview.md | 3 + src/doc/rustc-dev-guide/src/part-2-intro.md | 21 +++--- src/doc/rustc-dev-guide/src/part-3-intro.md | 8 +++ src/doc/rustc-dev-guide/src/part-4-intro.md | 12 ++++ .../{backend/backend.md => part-5-intro.md} | 30 ++++---- .../src/pat-exhaustive-checking.md | 7 ++ src/doc/rustc-dev-guide/src/syntax-intro.md | 8 +++ 13 files changed, 139 insertions(+), 60 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/ast-validation.md rename src/doc/rustc-dev-guide/src/{high-level-overview.md => compiler-src.md} (100%) create mode 100644 src/doc/rustc-dev-guide/src/feature-gate-ck.md create mode 100644 src/doc/rustc-dev-guide/src/overview.md create mode 100644 src/doc/rustc-dev-guide/src/part-3-intro.md create mode 100644 src/doc/rustc-dev-guide/src/part-4-intro.md rename src/doc/rustc-dev-guide/src/{backend/backend.md => part-5-intro.md} (66%) create mode 100644 src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md create mode 100644 src/doc/rustc-dev-guide/src/syntax-intro.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 366146185b602..d6cbe0645dd85 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 0882c40c06ad0..9637c312a355a 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ast-validation.md b/src/doc/rustc-dev-guide/src/ast-validation.md new file mode 100644 index 0000000000000..64e35bb93cf5a --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/high-level-overview.md b/src/doc/rustc-dev-guide/src/compiler-src.md similarity index 100% rename from src/doc/rustc-dev-guide/src/high-level-overview.md rename to src/doc/rustc-dev-guide/src/compiler-src.md diff --git a/src/doc/rustc-dev-guide/src/feature-gate-ck.md b/src/doc/rustc-dev-guide/src/feature-gate-ck.md new file mode 100644 index 0000000000000..3b3a07a31a627 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/feature-gate-ck.md @@ -0,0 +1,3 @@ +# Feature Gate Checking + +**TODO**: this chapter diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 52d1f46099a83..f353eacdf252b 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md new file mode 100644 index 0000000000000..140d2f352d305 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-2-intro.md b/src/doc/rustc-dev-guide/src/part-2-intro.md index 1a47f21e536ea..dc774f0c626aa 100644 --- a/src/doc/rustc-dev-guide/src/part-2-intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-3-intro.md b/src/doc/rustc-dev-guide/src/part-3-intro.md new file mode 100644 index 0000000000000..a1ec3ca90ade6 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-4-intro.md b/src/doc/rustc-dev-guide/src/part-4-intro.md new file mode 100644 index 0000000000000..00a74f308ffad --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/backend.md b/src/doc/rustc-dev-guide/src/part-5-intro.md similarity index 66% rename from src/doc/rustc-dev-guide/src/backend/backend.md rename to src/doc/rustc-dev-guide/src/part-5-intro.md index 0eaa720361e78..41c3eceb2bef8 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/pat-exhaustive-checking.md b/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md new file mode 100644 index 0000000000000..b29bb1351e8a6 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/syntax-intro.md b/src/doc/rustc-dev-guide/src/syntax-intro.md new file mode 100644 index 0000000000000..dd7e2d7359408 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 8cffef7b2002e8946fe8a3069221a85843bd611c Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Tue, 7 Apr 2020 01:04:51 -0400 Subject: [PATCH 0905/2516] update about-this-guide.md with new Guide sections --- .../rustc-dev-guide/src/about-this-guide.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 9637c312a355a..164e8f86969b7 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 e79cf128b72c6e757f97a4977f9fa152674bf071 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Tue, 7 Apr 2020 01:05:14 -0400 Subject: [PATCH 0906/2516] consistent section title casing --- src/doc/rustc-dev-guide/src/part-1-intro.md | 2 +- src/doc/rustc-dev-guide/src/part-2-intro.md | 2 +- src/doc/rustc-dev-guide/src/part-5-intro.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/part-1-intro.md b/src/doc/rustc-dev-guide/src/part-1-intro.md index 7597c71285ced..95d2f8fccf1d2 100644 --- a/src/doc/rustc-dev-guide/src/part-1-intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-2-intro.md b/src/doc/rustc-dev-guide/src/part-2-intro.md index dc774f0c626aa..04bb32cdbf8d5 100644 --- a/src/doc/rustc-dev-guide/src/part-2-intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-5-intro.md b/src/doc/rustc-dev-guide/src/part-5-intro.md index 41c3eceb2bef8..184d0ee3ae916 100644 --- a/src/doc/rustc-dev-guide/src/part-5-intro.md +++ b/src/doc/rustc-dev-guide/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 64a47ac3599b6bf6d52b4f24ad9c88c2f071b202 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Tue, 7 Apr 2020 12:15:57 -0400 Subject: [PATCH 0907/2516] mark-i-m review edits --- src/doc/rustc-dev-guide/src/about-this-guide.md | 10 +++++----- src/doc/rustc-dev-guide/src/part-2-intro.md | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 164e8f86969b7..58b0cb9f0c7bf 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-2-intro.md b/src/doc/rustc-dev-guide/src/part-2-intro.md index 04bb32cdbf8d5..04ae3f955b95f 100644 --- a/src/doc/rustc-dev-guide/src/part-2-intro.md +++ b/src/doc/rustc-dev-guide/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 2eabf5acfb0e9896df7301d5a53ca897fb173282 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 8 Apr 2020 01:52:05 -0500 Subject: [PATCH 0908/2516] fix a link (#672) --- src/doc/rustc-dev-guide/src/traits/chalk-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md index 88ae7b5a23269..64cb589c1b042 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk-overview.md +++ b/src/doc/rustc-dev-guide/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 4682b1d4f6e1452cf2e6297cb62201b3de482b25 Mon Sep 17 00:00:00 2001 From: Arlo Siemsen Date: Tue, 24 Mar 2020 15:34:03 -0700 Subject: [PATCH 0909/2516] 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/doc/rustc-dev-guide/src/debugging-support-in-rustc.md b/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md index a11edba7851e8..912ceffae2b5c 100644 --- a/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md +++ b/src/doc/rustc-dev-guide/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 ab1948fdb9f5ffbe44c2391460700ee38007a846 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sat, 11 Apr 2020 19:34:25 +0200 Subject: [PATCH 0910/2516] codegen tests: add link to LLVM FileCheck docs (#673) --- src/doc/rustc-dev-guide/src/tests/intro.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index a81255decf512..fd0e50c836610 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 6984d17a5eda87cbfeb46f2e7dccef0de862af57 Mon Sep 17 00:00:00 2001 From: Jan-Erik Rediger Date: Fri, 17 Apr 2020 14:16:56 +0200 Subject: [PATCH 0911/2516] 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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index dbe1f4c7ae4b2..5171e5f31fdde 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 46a0692ed5ead69a42351694891adb3a525cfd19 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 25 Mar 2020 23:26:17 -0500 Subject: [PATCH 0912/2516] add overview --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 - src/doc/rustc-dev-guide/src/overview.md | 326 +++++++++++++++++++++++- 2 files changed, 325 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index d6cbe0645dd85..28abd8d659beb 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 140d2f352d305..546f0ad13232d 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 90961eb27e610e7ad09e52cda225190c43931e0b Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 28 Mar 2020 06:47:45 -0500 Subject: [PATCH 0913/2516] correct a few links --- src/doc/rustc-dev-guide/src/overview.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 546f0ad13232d..c8b44d1c04ba8 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 e1aca82dc2ac98cb8b520dedf0365bb2b74e1926 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 2 Apr 2020 20:12:31 -0500 Subject: [PATCH 0914/2516] Apply Centril suggestions Co-Authored-By: Centril --- src/doc/rustc-dev-guide/src/overview.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index c8b44d1c04ba8..82aa6370553c5 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 4aaba07001a1457965c16d59c39faaddac88fedd Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Fri, 3 Apr 2020 01:41:04 -0400 Subject: [PATCH 0915/2516] [overview.md] Add command line argument parsing, lexer stages, and parser outline --- src/doc/rustc-dev-guide/src/overview.md | 132 ++++++++++++------------ 1 file changed, 66 insertions(+), 66 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 82aa6370553c5..ee876114940fb 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 8b7a798dfe2004f81397c6c668c964b04f28e4ee Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Fri, 3 Apr 2020 09:54:12 -0400 Subject: [PATCH 0916/2516] Update src/overview.md Co-Authored-By: LeSeulArtichaut --- src/doc/rustc-dev-guide/src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index ee876114940fb..efb96a68f46f7 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 1ff5a13872e676dd5976a95051e249b3f2cf7327 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Fri, 3 Apr 2020 09:59:09 -0400 Subject: [PATCH 0917/2516] Update src/overview.md Co-Authored-By: LeSeulArtichaut --- src/doc/rustc-dev-guide/src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index efb96a68f46f7..f0b2887de8b1d 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 0b8942d040c62cfc6248e00a18dfc32b63ccea58 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:30:45 -0500 Subject: [PATCH 0918/2516] fix old rustc-dev-guide links --- src/doc/rustc-dev-guide/src/overview.md | 42 ++++++++++++------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index f0b2887de8b1d..148d7ab348c1d 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 2fb3d1c2d6321720476a1bb82047f38b4db51ade Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:46:14 -0500 Subject: [PATCH 0919/2516] Add some entry points Co-Authored-By: LeSeulArtichaut --- src/doc/rustc-dev-guide/src/overview.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 148d7ab348c1d..9c6b71b76c1c8 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 d5d65558c556f28308f26cf5f258d73d05539df9 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:50:27 -0500 Subject: [PATCH 0920/2516] mention the hair --- src/doc/rustc-dev-guide/src/overview.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 9c6b71b76c1c8..0648ac7e1760c 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 d904a85b13571a09d3b7b9cdb6d524f5cac1a627 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:52:55 -0500 Subject: [PATCH 0921/2516] mention token stream as an IR --- src/doc/rustc-dev-guide/src/overview.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 0648ac7e1760c..cebff545dd09b 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 53f195ac76c35586045af7b440c7c2894519673e Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:57:14 -0500 Subject: [PATCH 0922/2516] correct the note about HAIR --- src/doc/rustc-dev-guide/src/overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index cebff545dd09b..8f6d00d7ecc0d 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 14913fa29cd1d3fdf10e85ee5f18a32ca91de0f2 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:59:51 -0500 Subject: [PATCH 0923/2516] Improve description of MIR Co-Authored-By: Centril --- src/doc/rustc-dev-guide/src/overview.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 8f6d00d7ecc0d..37a082070e82b 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 d8ee8411c325cfd63c32e8e3f59cb812496ced1f Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:02:04 -0500 Subject: [PATCH 0924/2516] break long sentence --- src/doc/rustc-dev-guide/src/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 37a082070e82b..3bd60904f3bf4 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 1d95efa40012086cb999fb3edb5f16b5c1c73ec7 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:04:36 -0500 Subject: [PATCH 0925/2516] add a note on tcx name --- src/doc/rustc-dev-guide/src/overview.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 3bd60904f3bf4..d92142e38ee6b 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 943409bdfc4070923e81fff3dbd2838ef1f0873a Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:17:04 -0500 Subject: [PATCH 0926/2516] write a bit about bootstrapping --- src/doc/rustc-dev-guide/src/overview.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index d92142e38ee6b..7b8cae839b09f 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 411ab09d62ca6bec427ff742a8b6dc6e90f3f34b Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:19:21 -0500 Subject: [PATCH 0927/2516] add a few todos --- src/doc/rustc-dev-guide/src/overview.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 7b8cae839b09f..350ff5523c012 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 887c4572661cd13c846b7f4c25b15474aea48cb4 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:20:48 -0500 Subject: [PATCH 0928/2516] line lengths --- src/doc/rustc-dev-guide/src/overview.md | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 350ff5523c012..26f7a2ad13a5b 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 6ad65d5cf8220e05df4fad9962c8ba15f4f17ad7 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:23:23 -0500 Subject: [PATCH 0929/2516] fix links --- src/doc/rustc-dev-guide/src/overview.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 26f7a2ad13a5b..4d5ff03b44430 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 253fbce8e6fe648706396a882d7d80d7b451bc04 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:27:24 -0500 Subject: [PATCH 0930/2516] remove a todo --- src/doc/rustc-dev-guide/src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 4d5ff03b44430..e2dc1e12b330f 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 797e95fdf3937d8ffbe072a546bd16cdd0faff04 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:30:40 -0500 Subject: [PATCH 0931/2516] add an entry point --- src/doc/rustc-dev-guide/src/overview.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index e2dc1e12b330f..9b67343af4bf5 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 60df0a806a4d6f325d59847efbfc6b7a8497ca21 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 14 Apr 2020 15:15:32 -0500 Subject: [PATCH 0932/2516] Improve wording Co-Authored-By: Santiago Pastorino --- src/doc/rustc-dev-guide/src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 9b67343af4bf5..7660b2c538443 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 a1c2be1410d95ac04fd665d358fd18c7d6c6525d Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:03:08 -0500 Subject: [PATCH 0933/2516] fix lexer entry point --- src/doc/rustc-dev-guide/src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 7660b2c538443..09285c5ba1509 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 949defa47c2759c8bd13d1b94803400c908b3de1 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 5 Apr 2020 22:20:44 -0400 Subject: [PATCH 0934/2516] [overview.md] add parser entry point links --- src/doc/rustc-dev-guide/src/overview.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 09285c5ba1509..432add21c26fd 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 13d674bcc22353e84a0de68a364f251f32e980d3 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:12:44 -0500 Subject: [PATCH 0935/2516] add a para on interning and arenas --- src/doc/rustc-dev-guide/src/overview.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 432add21c26fd..7085bb2a72ebc 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 553553b212b4eff4e3b70a9d1a7db47296a6e824 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:18:55 -0500 Subject: [PATCH 0936/2516] add entry points for type check and type inference Co-Authored-By: LeSeulArtichaut --- src/doc/rustc-dev-guide/src/overview.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 7085bb2a72ebc..a8a631b96d61d 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 88d21cce3bfc8dd2c4fe04da7ec7da5d658e6a26 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:30:39 -0500 Subject: [PATCH 0937/2516] some cleanup --- src/doc/rustc-dev-guide/src/overview.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index a8a631b96d61d..2565f902b38eb 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 e8ba37d8d9ef212ca248ce6e7ef368406d43252d Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:30:48 -0500 Subject: [PATCH 0938/2516] correct entry points for codegen --- src/doc/rustc-dev-guide/src/overview.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 2565f902b38eb..751a01ec08a36 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 35f766a50c430da02e87db08fbc8eacc2015afa2 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 5 Apr 2020 22:50:28 -0400 Subject: [PATCH 0939/2516] [overview.md] add documentation of lexer support for Unicode encoding --- src/doc/rustc-dev-guide/src/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 751a01ec08a36..d641718c8ee49 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 153b24cb1846ba126b773d3d4d43b31d3673d59a Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:34:23 -0500 Subject: [PATCH 0940/2516] update mono entry points --- src/doc/rustc-dev-guide/src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index d641718c8ee49..8bfa201183b41 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 4ecfcb1eb62b233dc328b80034970af32bcf537c Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:37:53 -0500 Subject: [PATCH 0941/2516] minor wording change on bootstrapping --- src/doc/rustc-dev-guide/src/overview.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 8bfa201183b41..744ef3b1f0295 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 14b6b0d130cddcbb7ce82eef158fc9d6bac52260 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:41:50 -0500 Subject: [PATCH 0942/2516] add intrinsics to glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 11ddb494f3912..5dc8f3801b313 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 6557f431c24c96c66e4f78af7bdc4b6bde23045a Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:48:04 -0500 Subject: [PATCH 0943/2516] fix links --- src/doc/rustc-dev-guide/src/overview.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 744ef3b1f0295..69e71723e014f 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 d3a0953a5fbbfc830a4010d781c206d9867cf12f Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Tue, 7 Apr 2020 00:27:39 -0400 Subject: [PATCH 0944/2516] [overview.md] add initial parser documentation --- src/doc/rustc-dev-guide/src/overview.md | 29 +++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 69e71723e014f..94ca5104873b6 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 91b4cd20b66b4a8aa0483b1b44eae5f3a6b977c7 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Tue, 7 Apr 2020 22:19:57 -0400 Subject: [PATCH 0945/2516] [overview.md] add lexer updates, parser updates includes feedback from matklad (lexer) and centril (parser) --- src/doc/rustc-dev-guide/src/overview.md | 26 +++++++++++-------------- 1 file changed, 11 insertions(+), 15 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 94ca5104873b6..3391952c7dbb0 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 dbd5f21e1960c34c12a26fe4e8e696b33de8e2c1 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 17:40:10 -0500 Subject: [PATCH 0946/2516] line length --- src/doc/rustc-dev-guide/src/overview.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 3391952c7dbb0..bdebd86e49215 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 3f4f20950234003c676892971c267778ee563bd6 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 17 Apr 2020 21:14:11 -0500 Subject: [PATCH 0947/2516] Remove various todos With some items added to https://github.com/rust-lang/rustc-dev-guide/issues/674 Co-Authored-By: Chris Simpkins --- src/doc/rustc-dev-guide/src/overview.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index bdebd86e49215..abe35188f597d 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 5708a4455df82558c531af9934fb7456c4dde77d Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 17 Apr 2020 21:19:25 -0500 Subject: [PATCH 0948/2516] add link to intrinsic --- src/doc/rustc-dev-guide/src/overview.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index abe35188f597d..e08f012f34ea7 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 ee95ff07a98a63fe05b9cfebeaaddf0d80fa6570 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 18 Apr 2020 11:54:09 +0900 Subject: [PATCH 0949/2516] Apply suggestions from code review Co-Authored-By: Chris Simpkins --- src/doc/rustc-dev-guide/src/overview.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index e08f012f34ea7..f2b36001301fb 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 35747eafda120545cd5511fa3d6eead541c06623 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 18 Apr 2020 11:40:16 -0500 Subject: [PATCH 0950/2516] Fix some whitespace (#677) --- src/doc/rustc-dev-guide/src/overview.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index f2b36001301fb..37e82822d7b6b 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 24ae2138a3f31c89ba41a2a60a89a530ed7e3620 Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Fri, 27 Mar 2020 16:29:11 +0100 Subject: [PATCH 0951/2516] 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/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index a41becfd0eecc..e545931cbb3a1 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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 1e8b3ec0e77c488480b9bee6e870b5aa85572130 Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Mon, 30 Mar 2020 17:03:24 +0200 Subject: [PATCH 0952/2516] Apply feedback. --- .../queries/incremental-compilation-in-detail.md | 14 ++++++++------ src/doc/rustc-dev-guide/src/query.md | 3 ++- 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index e545931cbb3a1..25db154fb90f5 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 6e2193bd3463e..4e795c6a23024 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 a97a93efa1ec82d067e2eebad7653c68eb06f3a4 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 18 Apr 2020 14:23:18 +0900 Subject: [PATCH 0953/2516] Apply suggestions from Zoxc --- .../src/queries/incremental-compilation-in-detail.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index 25db154fb90f5..d8716acdfffda 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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 c9b8bbec536ab4e6e374679a7f63a1a595d113c2 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Sun, 19 Apr 2020 12:54:45 -0300 Subject: [PATCH 0954/2516] Fix typo (#678) --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 7a4c972f20829..5945f0b027be9 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 488bf2b0ceb69348cfad4b65f0bfd988fbbc6965 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 0955/2516] Add diagnostics ICE-breakers page --- .../src/ice-breaker/diagnostics.md | 148 ++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/ice-breaker/diagnostics.md diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/diagnostics.md b/src/doc/rustc-dev-guide/src/ice-breaker/diagnostics.md new file mode 100644 index 0000000000000..3b5f353bca575 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 2fdd2e5289976dc14553aebf6dabb35ffd713232 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 0956/2516] review comments: move text to more relevant section --- src/doc/rustc-dev-guide/src/diagnostics.md | 104 ++++++++++++++++- .../src/ice-breaker/diagnostics.md | 109 +----------------- 2 files changed, 105 insertions(+), 108 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 50da15c220d98..51d6c27ae395d 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ice-breaker/diagnostics.md b/src/doc/rustc-dev-guide/src/ice-breaker/diagnostics.md index 3b5f353bca575..96450d8886c39 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 96e94b20139b112233a49461ed9eafad0b66da93 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 19 Apr 2020 13:07:05 -0500 Subject: [PATCH 0957/2516] Typo --- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 51d6c27ae395d..2212fc790dbf4 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 8f8568ece331f582a7dc2e7791305211815a524f Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Mon, 20 Apr 2020 15:16:27 +0200 Subject: [PATCH 0958/2516] Replace `rustc` with `rustc_middle` (#680) --- src/doc/rustc-dev-guide/src/compiler-src.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 472d1ea03b834..25b3baa3e4579 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 011e66658e9c7048993bf9dbec84ffb48d0c37da Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 24 Apr 2020 01:08:58 -0300 Subject: [PATCH 0959/2516] treat-err-as-bug=n means panic on nth error --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 89a763c41f5f4..d6d03ab1e8e57 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 9a4afb3dcf7e8784c998bf71c0b39d0c7060215b Mon Sep 17 00:00:00 2001 From: Charles Lew Date: Sun, 19 Apr 2020 22:48:45 +0800 Subject: [PATCH 0960/2516] Remove details about chalk and point to Chalk Book instead. --- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk.md | 43 ++ .../src/traits/goals-and-clauses.md | 270 ---------- .../src/traits/implied-bounds.md | 502 ------------------ src/doc/rustc-dev-guide/src/traits/index.md | 64 --- .../src/traits/lowering-rules.md | 416 --------------- .../src/traits/lowering-to-logic.md | 185 ------- .../rustc-dev-guide/src/traits/resolution.md | 2 +- src/doc/rustc-dev-guide/src/traits/slg.md | 302 ----------- src/doc/rustc-dev-guide/src/traits/wf.md | 469 ---------------- 15 files changed, 48 insertions(+), 3183 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/traits/associated-types.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/bibliography.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/canonical-queries.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/canonicalization.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/chalk-overview.md create mode 100644 src/doc/rustc-dev-guide/src/traits/chalk.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/implied-bounds.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/index.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/lowering-rules.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/slg.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/wf.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 28abd8d659beb..38634e26a0671 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/associated-types.md b/src/doc/rustc-dev-guide/src/traits/associated-types.md deleted file mode 100644 index 41ce5ac9e897b..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/bibliography.md b/src/doc/rustc-dev-guide/src/traits/bibliography.md deleted file mode 100644 index a0242d4c44b6d..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md deleted file mode 100644 index e15bdaae25c43..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md deleted file mode 100644 index d6d57d78509d0..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk-overview.md b/src/doc/rustc-dev-guide/src/traits/chalk-overview.md deleted file mode 100644 index 64cb589c1b042..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk.md b/src/doc/rustc-dev-guide/src/traits/chalk.md new file mode 100644 index 0000000000000..dcb0a244f0ec9 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md deleted file mode 100644 index ecd2ce1456b9d..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/implied-bounds.md b/src/doc/rustc-dev-guide/src/traits/implied-bounds.md deleted file mode 100644 index 5876f3b62164e..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/index.md b/src/doc/rustc-dev-guide/src/traits/index.md deleted file mode 100644 index 5544ce513d00c..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-rules.md b/src/doc/rustc-dev-guide/src/traits/lowering-rules.md deleted file mode 100644 index c780e7cf58212..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md deleted file mode 100644 index e1a6c1361c8de..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md index 2ba4516779cf6..7f73bfe4f9d63 100644 --- a/src/doc/rustc-dev-guide/src/traits/resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/slg.md b/src/doc/rustc-dev-guide/src/traits/slg.md deleted file mode 100644 index 74ec89fa0252a..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/wf.md b/src/doc/rustc-dev-guide/src/traits/wf.md deleted file mode 100644 index aa17f8c2c6ff2..0000000000000 --- a/src/doc/rustc-dev-guide/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 dcb4e26d03deaf6d767aae9879dca132860cc110 Mon Sep 17 00:00:00 2001 From: Charles Lew Date: Sun, 19 Apr 2020 23:06:05 +0800 Subject: [PATCH 0961/2516] Fix links and CI error. --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 6 +++--- src/doc/rustc-dev-guide/src/appendix/glossary.md | 6 +++--- src/doc/rustc-dev-guide/src/traits/chalk.md | 3 ++- src/doc/rustc-dev-guide/src/traits/lowering-module.md | 4 ++-- 4 files changed, 10 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index a4b18ecc071bd..327709c318860 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 5dc8f3801b313..ded31485b2a3a 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk.md b/src/doc/rustc-dev-guide/src/traits/chalk.md index dcb0a244f0ec9..dceb043541c5e 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md index 3c5bd7be5d54e..0efc82c3e8b7b 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-module.md +++ b/src/doc/rustc-dev-guide/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 171ce93e43b94f84bebcc1b3e041b768da014eca Mon Sep 17 00:00:00 2001 From: Charles Lew Date: Mon, 20 Apr 2020 22:24:38 +0800 Subject: [PATCH 0962/2516] Address review comments. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 6 +- .../src/appendix/code-index.md | 5 +- .../rustc-dev-guide/src/appendix/glossary.md | 6 +- .../src/traits/canonical-queries.md | 252 ++++++++++++++++ src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/regions.md | 9 - 9 files changed, 726 insertions(+), 85 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/traits/canonical-queries.md create mode 100644 src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md create mode 100644 src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md delete mode 100644 src/doc/rustc-dev-guide/src/traits/regions.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 38634e26a0671..ee4d7e3f27f11 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 327709c318860..76f4609cc81a8 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index ded31485b2a3a..a3b3826ea0c59 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md new file mode 100644 index 0000000000000..e15bdaae25c43 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk.md b/src/doc/rustc-dev-guide/src/traits/chalk.md index dceb043541c5e..70af2a1f52d3b 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md new file mode 100644 index 0000000000000..ecd2ce1456b9d --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md index 0efc82c3e8b7b..1efdcafb76b61 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-module.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md new file mode 100644 index 0000000000000..e1a6c1361c8de --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/regions.md b/src/doc/rustc-dev-guide/src/traits/regions.md deleted file mode 100644 index 4657529dc2bd7..0000000000000 --- a/src/doc/rustc-dev-guide/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 4182263c1fca82950528dcdbd2ba51581b48297a Mon Sep 17 00:00:00 2001 From: Charles Lew Date: Mon, 20 Apr 2020 22:36:05 +0800 Subject: [PATCH 0963/2516] Fix links. --- .../rustc-dev-guide/src/traits/canonical-queries.md | 11 +++-------- .../rustc-dev-guide/src/traits/goals-and-clauses.md | 12 ++++++------ .../rustc-dev-guide/src/traits/lowering-to-logic.md | 6 +++--- 3 files changed, 12 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md index e15bdaae25c43..5ba450d4ef1f4 100644 --- a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index ecd2ce1456b9d..f4ceb99a03d27 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md index e1a6c1361c8de..cc8b3bf800cb9 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md +++ b/src/doc/rustc-dev-guide/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 c8ce4b264b0aaaee419c6d0221cd09d2054795d9 Mon Sep 17 00:00:00 2001 From: Charles Lew Date: Sat, 25 Apr 2020 09:17:48 +0800 Subject: [PATCH 0964/2516] Address review comments. Co-Authored-By: Who? Me?! --- src/doc/rustc-dev-guide/src/SUMMARY.md | 8 ++++---- src/doc/rustc-dev-guide/src/traits/lowering-module.md | 2 ++ 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index ee4d7e3f27f11..fe040d9e2e6f8 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md index 1efdcafb76b61..8795cb79c6f9d 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-module.md +++ b/src/doc/rustc-dev-guide/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 1701ef03fc848f209ca8fd2f702ad8e5ffb39936 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 25 Apr 2020 14:23:59 -0500 Subject: [PATCH 0965/2516] 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/doc/rustc-dev-guide/src/ice-breaker/diagnostics.md diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/diagnostics.md b/src/doc/rustc-dev-guide/src/ice-breaker/diagnostics.md deleted file mode 100644 index 96450d8886c39..0000000000000 --- a/src/doc/rustc-dev-guide/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 09fbca820499c5e1ab4093b4de39d94ada78ed5b Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 27 Apr 2020 17:40:49 -0300 Subject: [PATCH 0966/2516] Fix sub-diagnostic typo --- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 2212fc790dbf4..b77e4547fe03c 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 5c7c077ab5cea10215bd22ef0848f1cff3bee1a5 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 27 Apr 2020 17:42:10 -0300 Subject: [PATCH 0967/2516] Remove extra the --- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index b77e4547fe03c..ab36e428f3ce8 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 70207c4b12fffaf8819238df5c55d23184f08b75 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 28 Apr 2020 16:19:37 -0300 Subject: [PATCH 0968/2516] It's just ICE-breaker (#685) --- src/doc/rustc-dev-guide/src/ice-breaker/about.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/ice-breaker/about.md index 642fbe4a1d9c3..d9c724532a6e9 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/about.md +++ b/src/doc/rustc-dev-guide/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 1cac658b1dd26a171a1b025445e4c0cda40d07fc Mon Sep 17 00:00:00 2001 From: Hanif Ariffin Date: Thu, 30 Apr 2020 21:18:21 -0400 Subject: [PATCH 0969/2516] Minute formatting fix --- src/doc/rustc-dev-guide/src/queries/profiling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index 37b1bc97b4fb0..958dd33376951 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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 09b7ba109275ad8fb52ccd45598b1977361a055e Mon Sep 17 00:00:00 2001 From: Hanif Ariffin Date: Thu, 30 Apr 2020 08:48:42 -0400 Subject: [PATCH 0970/2516] 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. --- .../rustc-dev-guide/src/queries/incremental-compilation.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md index be8580f2db099..499b3282f1b38 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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 18b4dbccf62b5676a2028d0fb5e5dd8961803b0f Mon Sep 17 00:00:00 2001 From: Hanif Ariffin Date: Thu, 30 Apr 2020 19:03:49 -0400 Subject: [PATCH 0971/2516] Update src/queries/incremental-compilation.md Removed `at`. Co-authored-by: LeSeulArtichaut --- src/doc/rustc-dev-guide/src/queries/incremental-compilation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md index 499b3282f1b38..394b4de745c9a 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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 787a410dc4941c787593b9ab1ec5c49fab3d1b31 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 30 Apr 2020 18:59:32 -0500 Subject: [PATCH 0972/2516] tidy --- .../rustc-dev-guide/src/queries/incremental-compilation.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md index 394b4de745c9a..210d5b3918e7f 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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 fbc2c3fb1965c5d39c3ecff15170a4e9de4e0903 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 1 May 2020 16:08:23 +0200 Subject: [PATCH 0973/2516] I confirmed this --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index d6d03ab1e8e57..780f5d87154bd 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 5ddf4f6ad1fe1285c4d5a1154e4d127709e8e3f6 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 1 May 2020 16:05:15 +0200 Subject: [PATCH 0974/2516] improve info regarding incremental a little --- src/doc/rustc-dev-guide/src/tests/running.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 4126341aad1ff..a6303c1a6fc55 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 3f7d16743cb3b35782e9c680e704276763aeb10e Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Sat, 2 May 2020 15:56:33 +0200 Subject: [PATCH 0975/2516] Fix example for winnowing --- src/doc/rustc-dev-guide/src/traits/resolution.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md index 7f73bfe4f9d63..236ca966d4bbd 100644 --- a/src/doc/rustc-dev-guide/src/traits/resolution.md +++ b/src/doc/rustc-dev-guide/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 a3cdc0e4e8d878f35a3f0674581a5238fb011681 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 30 Apr 2020 22:43:52 -0500 Subject: [PATCH 0976/2516] Reduce cache timeout to catch broken links faster. --- src/doc/rustc-dev-guide/book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 3d90479cb2e7f..c342c38748ffa 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 4112e2614ff0cfe850b07ff8dad7ed0e3a4449fa Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 6 May 2020 13:59:28 -0500 Subject: [PATCH 0977/2516] add a bit more on parallel compilation --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/parallel-rustc.md | 45 +++++++++++++++++++ 2 files changed, 46 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/parallel-rustc.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index fe040d9e2e6f8..f1efcf597db89 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md new file mode 100644 index 0000000000000..c8214af38cc8e --- /dev/null +++ b/src/doc/rustc-dev-guide/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 28751222f9e0f654f7ede1fa1137f8e73820ccd1 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 6 May 2020 17:01:45 -0500 Subject: [PATCH 0978/2516] typo Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/parallel-rustc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index c8214af38cc8e..66a692a91b47a 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 3961c0861baf2eec560fd0c9179e4d6ebfd7fa44 Mon Sep 17 00:00:00 2001 From: Hanif Ariffin Date: Thu, 7 May 2020 10:44:39 -0400 Subject: [PATCH 0979/2516] Added link to the `ty::Adt` (#696) * Added link to the `ty::Adt` * Formatting fixes Thanks @JohnTitor Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/ty.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 76e71584fd5fe..37f45cde17ec2 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 05aa62aa321e37c0fc560ddf12b1d237ead4421d Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 2 May 2020 14:46:48 -0700 Subject: [PATCH 0980/2516] Example of getting diagnostics --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/rustc-driver-getting-diagnostics.md | 101 ++++++++++++++++++ 2 files changed, 102 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index f1efcf597db89..87c638ffd9ec8 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md b/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md new file mode 100644 index 0000000000000..d4b395555398a --- /dev/null +++ b/src/doc/rustc-dev-guide/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 cdba65df35f2b51bc5e3ddf4c9678b0b06df4913 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 2 May 2020 15:06:21 -0700 Subject: [PATCH 0981/2516] Line length --- .../rustc-dev-guide/src/rustc-driver-getting-diagnostics.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md b/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md index d4b395555398a..72649d6a225a8 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md +++ b/src/doc/rustc-dev-guide/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 d4de7a663d337f627252a6b7926422a9f7024968 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Tue, 5 May 2020 21:41:11 -0700 Subject: [PATCH 0982/2516] Reference complete examples --- .../examples/rustc-driver-example.rs | 56 +++------ .../rustc-driver-getting-diagnostics.rs | 89 ++++++++++++++ .../rustc-driver-interacting-with-the-ast.rs | 78 ++++++++++++ .../src/rustc-driver-getting-diagnostics.md | 114 ++++-------------- .../rustc-driver-interacting-with-the-ast.md | 18 +-- 5 files changed, 222 insertions(+), 133 deletions(-) create mode 100644 src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs create mode 100644 src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs diff --git a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs index 62c80b4aedb80..4b0b23aaa52f8 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs new file mode 100644 index 0000000000000..cf08ed87fc30a --- /dev/null +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs new file mode 100644 index 0000000000000..105ee00194eb3 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md b/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md index 72649d6a225a8..27ca2ca12b8fa 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md b/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md index 1749c9db4131a..0cdc84393c1fb 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md +++ b/src/doc/rustc-dev-guide/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 cda3507c907cad6a7b2c81cd54d5ba75780afa78 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 25 Apr 2020 13:09:19 -0500 Subject: [PATCH 0983/2516] some cleanup in the macros chapter --- .../rustc-dev-guide/src/macro-expansion.md | 222 +++++------------- 1 file changed, 58 insertions(+), 164 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 279598270551d..e7a09d31c617b 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 538337e9ed4ff8bf7f5c95b0d7b86ae5862fa8d5 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 25 Apr 2020 13:42:01 -0500 Subject: [PATCH 0984/2516] start working through discussion --- .../rustc-dev-guide/src/macro-expansion.md | 249 ++++-------------- 1 file changed, 51 insertions(+), 198 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index e7a09d31c617b..002e077d808d5 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 15f3f71e29c43e8d5647c45ac9baabbbc01bdc01 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 25 Apr 2020 15:18:15 -0500 Subject: [PATCH 0985/2516] more notetaking --- .../rustc-dev-guide/src/macro-expansion.md | 148 ++++-------------- 1 file changed, 34 insertions(+), 114 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 002e077d808d5..fc42ae8647024 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 4296f13747891fa2a24e5322e0fc5ed92d08c1d4 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 29 Apr 2020 21:07:21 -0500 Subject: [PATCH 0986/2516] finish going through discussion --- .../rustc-dev-guide/src/macro-expansion.md | 366 +++++------------- 1 file changed, 89 insertions(+), 277 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index fc42ae8647024..fc04c6f8d7164 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 b4641e0e959b80aab9be06b8ae218b3e460ac3e9 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 29 Apr 2020 21:13:35 -0500 Subject: [PATCH 0987/2516] get rid of old todo --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index fc04c6f8d7164..b0f23096f69f0 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 52ffc3edfcbef33f64b13b293d858955e93f2181 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 11:28:44 -0500 Subject: [PATCH 0988/2516] add a bit to part 3 intro --- src/doc/rustc-dev-guide/src/part-3-intro.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/part-3-intro.md b/src/doc/rustc-dev-guide/src/part-3-intro.md index a1ec3ca90ade6..2af8cce23e22e 100644 --- a/src/doc/rustc-dev-guide/src/part-3-intro.md +++ b/src/doc/rustc-dev-guide/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 41c1e3d7f5077b26e1443b5db0f95c59b1cd0843 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 11:33:05 -0500 Subject: [PATCH 0989/2516] add a bit to syntax intro --- src/doc/rustc-dev-guide/src/syntax-intro.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/syntax-intro.md b/src/doc/rustc-dev-guide/src/syntax-intro.md index dd7e2d7359408..43ef445774668 100644 --- a/src/doc/rustc-dev-guide/src/syntax-intro.md +++ b/src/doc/rustc-dev-guide/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 6b1f713d7296ed71ba2dfda32472f2e6a9fe7828 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 11:33:37 -0500 Subject: [PATCH 0990/2516] reorder some chapters --- src/doc/rustc-dev-guide/src/SUMMARY.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 87c638ffd9ec8..94768bc83e372 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 9fa8ceeb1bf902ab0804d30c0445dea0987ef7aa Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 11:36:47 -0500 Subject: [PATCH 0991/2516] add note about macros in parser chapter --- src/doc/rustc-dev-guide/src/the-parser.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index c84ac4ea2e168..c0f2a071b53ac 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 710677476cefb57252d3f8923b8ee0e1d6891675 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 11:50:37 -0500 Subject: [PATCH 0992/2516] reorganize the macro expansion chapter --- .../rustc-dev-guide/src/macro-expansion.md | 383 +++++++++--------- 1 file changed, 201 insertions(+), 182 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index b0f23096f69f0..27d9d45d1f874 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 60f177e87e0273ab613c81c857a9b262ce9c571d Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 12:36:16 -0500 Subject: [PATCH 0993/2516] expand some notes about expansion :P --- .../rustc-dev-guide/src/macro-expansion.md | 120 ++++++++++++------ .../rustc-dev-guide/src/name-resolution.md | 23 ++++ 2 files changed, 104 insertions(+), 39 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 27d9d45d1f874..f076ed5fa48bb 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index f3aacba001706..d08fe43f3caed 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 2c3efb76cfb9c2ad9272cbd5e2c860d8fad4a080 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 19:13:18 -0500 Subject: [PATCH 0994/2516] add a bit more info about eager exp --- .../rustc-dev-guide/src/macro-expansion.md | 21 ++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index f076ed5fa48bb..500b1a78cd0ed 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 5e26576ae0f01f1ea801b388aafd6218c7d3c040 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 20:08:36 -0500 Subject: [PATCH 0995/2516] expand notes on expansion heirarchies --- .../rustc-dev-guide/src/macro-expansion.md | 185 ++++++++++++------ 1 file changed, 128 insertions(+), 57 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 500b1a78cd0ed..6bd8096803790 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 0786eff8ae38f70e6daa337df8d4dc3550c5d7a5 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 20:49:46 -0500 Subject: [PATCH 0996/2516] sprinkle around a bunch of links --- .../rustc-dev-guide/src/macro-expansion.md | 122 ++++++++++++------ 1 file changed, 85 insertions(+), 37 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 6bd8096803790..faf9bad45e74b 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 2ae25c7d257eb83cd1c3b96ebdeda540b0dd12da Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 21:22:25 -0500 Subject: [PATCH 0997/2516] SPRINKLE ALL THE THINGS --- .../rustc-dev-guide/src/macro-expansion.md | 88 ++++++++++++------- src/doc/rustc-dev-guide/src/the-parser.md | 3 +- 2 files changed, 57 insertions(+), 34 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index faf9bad45e74b..5cd3c067ed1b8 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index c0f2a071b53ac..da318c9ef3add 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 25c2d78353f3476ed4f8eb2aa27e69c82bf3b6be Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 22:41:58 -0500 Subject: [PATCH 0998/2516] fix line length --- src/doc/rustc-dev-guide/src/macro-expansion.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 5cd3c067ed1b8..d8b5c392c5160 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 5792a086e328308b0031b40c78816efcb6b5a27c Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 22:47:13 -0500 Subject: [PATCH 0999/2516] fix some links --- src/doc/rustc-dev-guide/src/macro-expansion.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index d8b5c392c5160..50e4dc2a77b61 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 3c3a65f56471e43eeb8f15a696229afd08c13a01 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 2 May 2020 20:54:27 -0500 Subject: [PATCH 1000/2516] Typos Co-authored-by: Chris Simpkins --- .../rustc-dev-guide/src/macro-expansion.md | 48 +++++++++---------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 50e4dc2a77b61..a29f56b7c2377 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 278f931731cb6f3c189430a8ac071a3c72018a05 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 2 May 2020 21:09:44 -0500 Subject: [PATCH 1001/2516] Use full path of span Co-authored-by: Chris Simpkins --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index a29f56b7c2377..22895a68d7222 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 b812b1bf0f4e052a5dd23c3210ebf3fb174a956d Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 2 May 2020 21:02:54 -0500 Subject: [PATCH 1002/2516] move discussion of eager expansion to the end --- .../rustc-dev-guide/src/macro-expansion.md | 60 ++++++++++--------- 1 file changed, 32 insertions(+), 28 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 22895a68d7222..aa6680f45ca03 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 bf4e974ef4103c36ef73ffa37e02f7677864016d Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 2 May 2020 21:10:14 -0500 Subject: [PATCH 1003/2516] add some section headers --- .../rustc-dev-guide/src/macro-expansion.md | 50 +++++++++++-------- 1 file changed, 28 insertions(+), 22 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index aa6680f45ca03..ea1240fc4a18f 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 9c85446715893e9f87f922ce00701b232f3c53c5 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 8 May 2020 09:36:10 -0500 Subject: [PATCH 1004/2516] Typo Co-authored-by: Chris Simpkins --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index ea1240fc4a18f..7961d0cf1262e 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 66b25af58118495c31448efbd7ed5a3ce897c87a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 8 May 2020 10:40:35 -0500 Subject: [PATCH 1005/2516] Fix typo --- src/doc/rustc-dev-guide/src/parallel-rustc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index 66a692a91b47a..add902d3a6dae 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 b2b037bdec2f56eb76f88501619fbb3018866c51 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 11 May 2020 07:57:46 +0200 Subject: [PATCH 1006/2516] glossary: intro feels like not adding much (#699) --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index a3b3826ea0c59..c8738c998f7e1 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 06a041be8508e9aaefc51b213737641ae9d3703d Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 11 May 2020 14:51:33 -0500 Subject: [PATCH 1007/2516] fix links (#702) --- src/doc/rustc-dev-guide/src/test-implementation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/test-implementation.md b/src/doc/rustc-dev-guide/src/test-implementation.md index cffc62ceca953..a5ddd9135e76f 100644 --- a/src/doc/rustc-dev-guide/src/test-implementation.md +++ b/src/doc/rustc-dev-guide/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 050fc9c2cd0cbe34c7d0c9e05ae692c76b9ff7b4 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sun, 10 May 2020 16:37:26 +0200 Subject: [PATCH 1008/2516] glossary: make soundness definition more readable --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index c8738c998f7e1..b89050034c274 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 adb56d92f63ce527d74ed12d98c14729c6b5767e Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 11 May 2020 07:56:48 +0200 Subject: [PATCH 1009/2516] Update src/appendix/glossary.md Co-authored-by: Who? Me?! --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index b89050034c274..d7cf30b913cdf 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 73eef7e7b1761dcdf82b03d0a2442c6fc0dbc9a0 Mon Sep 17 00:00:00 2001 From: Jade McGough Date: Sat, 16 May 2020 18:19:52 -0700 Subject: [PATCH 1010/2516] Add missing closing paren (#705) --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 5171e5f31fdde..16d3e14623f04 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 89aba46138ebbf129e7cf774216693d8b56f1924 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Mon, 18 May 2020 22:30:27 -0400 Subject: [PATCH 1011/2516] typo fix (#706) --- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index ab36e428f3ce8..c68b76f03ae8c 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 c0d248e5ec8677e09d7755c2ab3fc4b6582df54f Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Sat, 23 May 2020 16:25:53 -0400 Subject: [PATCH 1012/2516] Fix BodyId link typo in glossary (#709) * Fix BodyId link typo in glossary * Fix broken link to rustc_middle's Predicate --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- src/doc/rustc-dev-guide/src/memory.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index d7cf30b913cdf..0b4aad6583ea4 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/memory.md b/src/doc/rustc-dev-guide/src/memory.md index 620b7d858e98b..43b3746f00e0d 100644 --- a/src/doc/rustc-dev-guide/src/memory.md +++ b/src/doc/rustc-dev-guide/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 93efcba5a2b3940b028929e8ffa47e9d79068623 Mon Sep 17 00:00:00 2001 From: Adam Perry Date: Sat, 23 May 2020 13:40:23 -0700 Subject: [PATCH 1013/2516] Extern blocks are allowed for #[track_caller] now. (#710) since https://github.com/rust-lang/rust/pull/70916 --- src/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md b/src/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md index 5f11dad30b3bb..c6dc89f650af2 100644 --- a/src/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md +++ b/src/doc/rustc-dev-guide/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 124eaa06ccb005561c3a125d75ff00773f223746 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 25 May 2020 17:23:15 +0900 Subject: [PATCH 1014/2516] Update docs related to const-eval/Miri (#676) * Update docs related to const-eval Co-authored-by: Ralf Jung --- src/doc/rustc-dev-guide/src/const-eval.md | 41 +++++++++++++---------- src/doc/rustc-dev-guide/src/miri.md | 30 ++++++++--------- 2 files changed, 39 insertions(+), 32 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/const-eval.md b/src/doc/rustc-dev-guide/src/const-eval.md index aaa2ed2d6cc97..2a5c5d2f97505 100644 --- a/src/doc/rustc-dev-guide/src/const-eval.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index 16f2a18f2bba1..76996271d7272 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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 e08f5d7f95be6e3b7ab46ce0d0a20def0c964e59 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 27 May 2020 00:21:56 +0900 Subject: [PATCH 1015/2516] Rename `upvars` query to `upvars_mentioned` --- src/doc/rustc-dev-guide/src/closure.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index d4f9fc3852b1f..0f9b13965358c 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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 c660b6659f1a369691b981c2fafc79e126aaa0d6 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 27 May 2020 14:17:39 +0200 Subject: [PATCH 1016/2516] Add section for debugging rustc type layouts (#720) --- .../rustc-dev-guide/src/compiler-debugging.md | 59 +++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 780f5d87154bd..a499224ae1097 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 fd60d509c5ec31024b828f68b24437dfccbbb8a2 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 27 May 2020 23:04:56 +0800 Subject: [PATCH 1017/2516] It looks like the high-level-overview was renamed (#721) --- src/doc/rustc-dev-guide/src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 4e795c6a23024..be84fec54ceea 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 81edc4bb4d84e57a37e19284538ed778c540f288 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 26 May 2020 18:21:46 -0700 Subject: [PATCH 1018/2516] Add some guidelines on the CLI. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/cli.md | 29 ++++++++++++++++++++++++++ 2 files changed, 30 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/cli.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 94768bc83e372..19afb765be75f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/cli.md b/src/doc/rustc-dev-guide/src/cli.md new file mode 100644 index 0000000000000..0e04b38180ae4 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 be3dba039bf23b7aa94fc57580f6ec5f8446b7dd Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 27 May 2020 09:21:23 -0700 Subject: [PATCH 1019/2516] Apply suggestions from code review Co-authored-by: Chris Simpkins Co-authored-by: Who? Me?! --- src/doc/rustc-dev-guide/src/cli.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/cli.md b/src/doc/rustc-dev-guide/src/cli.md index 0e04b38180ae4..bbb7bae24c5f0 100644 --- a/src/doc/rustc-dev-guide/src/cli.md +++ b/src/doc/rustc-dev-guide/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 fd04d6e662e40b60907333671db23e16ed787402 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 27 May 2020 09:24:53 -0700 Subject: [PATCH 1020/2516] Move CLI to part 3. --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 19afb765be75f..0a9dc77737795 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 69801e4c014eadad6e70b99fdb14e44a5bf105ad Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 27 May 2020 10:04:09 +0200 Subject: [PATCH 1021/2516] Add definition of `niche` to the glossary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 0b4aad6583ea4..f2fdfe2171876 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 fbae21f75644f10490fbf73edbb150d6a5db0912 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 27 May 2020 16:36:00 +0200 Subject: [PATCH 1022/2516] Fix typo Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index f2fdfe2171876..6f770a77731f5 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 077a5a73cfcab95df6cf2ced59fc5fa877cf9d16 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 27 May 2020 20:17:27 +0200 Subject: [PATCH 1023/2516] Apply suggestions from code review Co-authored-by: Who? Me?! --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 6f770a77731f5..dddf628f27748 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 8d7e1900ec5dee0efc25257424a4f0b61b2fc929 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 26 May 2020 18:20:47 -0700 Subject: [PATCH 1024/2516] Add some guidelines on diagnostics. --- src/doc/rustc-dev-guide/src/diagnostics.md | 160 ++++++++++++++++++++- 1 file changed, 159 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index c68b76f03ae8c..adcf598d565fd 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 febe73f26af2bfe8d5d7c3d370c739b388a18275 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 27 May 2020 09:26:28 -0700 Subject: [PATCH 1025/2516] Apply suggestions from code review Co-authored-by: Who? Me?! Co-authored-by: Chris Simpkins --- src/doc/rustc-dev-guide/src/diagnostics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index adcf598d565fd..de081bb2067ad 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 fb5af97d8725b5c6cdbc91877987b960113fe6de Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 27 May 2020 09:45:18 -0700 Subject: [PATCH 1026/2516] Updates from review. --- src/doc/rustc-dev-guide/src/diagnostics.md | 30 ++++++++++++++-------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index de081bb2067ad..b85b198b0ee32 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 5a0078ec123f4f8f1d7f3edd465036323eb22538 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 27 May 2020 15:18:47 -0700 Subject: [PATCH 1027/2516] Clarify lint vs fixed diagnostic. --- src/doc/rustc-dev-guide/src/diagnostics.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index b85b198b0ee32..a9634ba63e249 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 30a732758164b302176f10687856049618a633a6 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Thu, 28 May 2020 13:43:22 -0400 Subject: [PATCH 1028/2516] Expand error annotations section with examples (#724) * expand error annotations section with examples Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/tests/adding.md | 67 ++++++++++++++++++++- 1 file changed, 64 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index dadd8e2c15fdb..e2a397a5b6aaa 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 6edb8366dd081529757aa0feac0c7bfa0f4a7a89 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Thu, 28 May 2020 16:16:34 -0400 Subject: [PATCH 1029/2516] add documentation of UI test error annotation substring support --- src/doc/rustc-dev-guide/src/tests/adding.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index e2a397a5b6aaa..e20d7fdc1d728 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 e371b6055b48bd17d2f8d572b4bb6e99b897eb69 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Thu, 28 May 2020 17:10:21 -0400 Subject: [PATCH 1030/2516] Update src/tests/adding.md Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/tests/adding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index e20d7fdc1d728..9dcb893261a13 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 9d0149ed37c47eef29d2a717814a37227dd909aa Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 29 May 2020 18:20:24 +0200 Subject: [PATCH 1031/2516] Document `RUSTFLAGS_STAGE_` bootstrap environment variables (#728) * Document `RUSTFLAGS_STAGE_` * Fix typos Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 5bdc8dc6f18ba..5ba8ef88d3754 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 b4fe490065fce6da000b11eabaf55705db01242b Mon Sep 17 00:00:00 2001 From: Tom Eccles Date: Fri, 29 May 2020 14:18:52 +0100 Subject: [PATCH 1032/2516] Document remote testing --- src/doc/rustc-dev-guide/src/tests/intro.md | 84 +++++++++++++++++++--- 1 file changed, 74 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index fd0e50c836610..2fa1363d0adeb 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 90e8910692a70134e986f8204f1d769f728c682e Mon Sep 17 00:00:00 2001 From: Tom Eccles Date: Fri, 29 May 2020 15:01:42 +0100 Subject: [PATCH 1033/2516] Document more //ignore-X test headers --- src/doc/rustc-dev-guide/src/tests/adding.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 9dcb893261a13..15fff1ff3ecee 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 ed6374e17041be33ee24acf643ca2010ad648c5b Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 30 May 2020 08:49:25 +0900 Subject: [PATCH 1034/2516] Update lint declaration example (#713) --- src/doc/rustc-dev-guide/src/diagnostics.md | 50 +++++++++++++--------- 1 file changed, 30 insertions(+), 20 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index a9634ba63e249..428688fd3beab 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 881554cdec3252e7d71a6e1f6bdf49434ce13141 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 1 Jun 2020 20:48:29 -0500 Subject: [PATCH 1035/2516] Playing with travis images --- src/doc/rustc-dev-guide/.travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index df48ef6dfa333..e6c5e431ed264 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.travis.yml @@ -1,4 +1,5 @@ language: rust +dist: focal rust: - nightly cache: From 7e0b5299a8f514e8f9659c0b61a9c62910cc24da Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 1 Jun 2020 22:16:17 -0500 Subject: [PATCH 1036/2516] Update .travis.yml --- src/doc/rustc-dev-guide/.travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index e6c5e431ed264..e4a72f7c60ca2 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.travis.yml @@ -1,5 +1,5 @@ language: rust -dist: focal +dist: bionic rust: - nightly cache: From 1bf3ec8ea07a54745b2dcf1a8d68aa41d4fd3574 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 2 Jun 2020 19:24:54 -0500 Subject: [PATCH 1037/2516] Make travis badge link to travis --- src/doc/rustc-dev-guide/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index a6658b023b627..8f7db233ef477 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 5e260c53e0ec0b202f4a88cae7a7c7ecf2307e3e Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 3 Jun 2020 22:46:04 +0200 Subject: [PATCH 1038/2516] 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 --- .../rustc-dev-guide/src/building/suggested.md | 69 +++++++++++++++++-- 1 file changed, 64 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index e9b48a7efd916..4491a3b7233f5 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 be16b8c9ef3bb85cff1d51839bb0ef22634c9a9c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 5 Jun 2020 10:10:01 -0500 Subject: [PATCH 1039/2516] Fix link (#734) --- src/doc/rustc-dev-guide/src/appendix/background.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/background.md b/src/doc/rustc-dev-guide/src/appendix/background.md index 50a550dc8d09e..b688d2c75dbe7 100644 --- a/src/doc/rustc-dev-guide/src/appendix/background.md +++ b/src/doc/rustc-dev-guide/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 1dce1d11c09f120e1e51fbbc00067c9a29933bc8 Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Thu, 4 Jun 2020 14:34:11 +0200 Subject: [PATCH 1040/2516] words --- .../region_inference/placeholders_and_universes.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md index eda8e6ff1dd3a..169f1b486c9ff 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/doc/rustc-dev-guide/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 c89c8b5be5d8e1f759ee639280088ac0c67f14e3 Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Fri, 5 Jun 2020 11:33:55 +0200 Subject: [PATCH 1041/2516] braces --- src/doc/rustc-dev-guide/src/ty.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 37f45cde17ec2..6197a22be8ff4 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 2d4344fed1065bd4548493a37f136cc7b95d8b93 Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Fri, 5 Jun 2020 18:06:39 +0200 Subject: [PATCH 1042/2516] update conventions (#735) * update conventions * typo Co-authored-by: Santiago Pastorino Co-authored-by: Santiago Pastorino --- src/doc/rustc-dev-guide/src/conventions.md | 23 +++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 3f957cc27b341..b9001ee0bbea0 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 71e7090872d8d2bc2e5c036df2a1243771dbe741 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 5 Jun 2020 11:11:09 -0500 Subject: [PATCH 1043/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/appendix/background.md | 146 +++++++++++++++++- .../rustc-dev-guide/src/appendix/glossary.md | 1 + .../rustc-dev-guide/src/early-late-bound.md | 107 +++++++++++++ 4 files changed, 253 insertions(+), 2 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/early-late-bound.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 0a9dc77737795..f45e8ba966359 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/background.md b/src/doc/rustc-dev-guide/src/appendix/background.md index b688d2c75dbe7..fe69f6bfda689 100644 --- a/src/doc/rustc-dev-guide/src/appendix/background.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index dddf628f27748..f8042170c0832 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/early-late-bound.md b/src/doc/rustc-dev-guide/src/early-late-bound.md new file mode 100644 index 0000000000000..a703cbab5dd63 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 6e84ec7882b6c3354fcb8b609180cb97756399db Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 5 Jun 2020 12:42:45 -0500 Subject: [PATCH 1044/2516] do a rebase before testing (#737) --- src/doc/rustc-dev-guide/.travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index e4a72f7c60ca2..3e5febe301dbb 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 59eb20e0c37c194f47e8b0a94521ef20ad6beb47 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 1045/2516] Document needs-* compiletest directives --- src/doc/rustc-dev-guide/src/tests/adding.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 15fff1ff3ecee..1df17ae01199d 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 4bac95a8b33768e8bdd85798310063ae0d36a161 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 9 Jun 2020 15:42:00 -0400 Subject: [PATCH 1046/2516] 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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/{ice-breaker => notification-groups}/about.md (100%) rename src/doc/rustc-dev-guide/src/{ice-breaker => notification-groups}/cleanup-crew.md (100%) rename src/doc/rustc-dev-guide/src/{ice-breaker => notification-groups}/llvm.md (77%) create mode 100644 src/doc/rustc-dev-guide/src/notification-groups/windows.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index f45e8ba966359..a86eedd6c20f5 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ice-breaker/about.md b/src/doc/rustc-dev-guide/src/notification-groups/about.md similarity index 100% rename from src/doc/rustc-dev-guide/src/ice-breaker/about.md rename to src/doc/rustc-dev-guide/src/notification-groups/about.md diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/cleanup-crew.md b/src/doc/rustc-dev-guide/src/notification-groups/cleanup-crew.md similarity index 100% rename from src/doc/rustc-dev-guide/src/ice-breaker/cleanup-crew.md rename to src/doc/rustc-dev-guide/src/notification-groups/cleanup-crew.md diff --git a/src/doc/rustc-dev-guide/src/ice-breaker/llvm.md b/src/doc/rustc-dev-guide/src/notification-groups/llvm.md similarity index 77% rename from src/doc/rustc-dev-guide/src/ice-breaker/llvm.md rename to src/doc/rustc-dev-guide/src/notification-groups/llvm.md index a6291a8c2ea82..d657231f2d6fd 100644 --- a/src/doc/rustc-dev-guide/src/ice-breaker/llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/notification-groups/windows.md b/src/doc/rustc-dev-guide/src/notification-groups/windows.md new file mode 100644 index 0000000000000..328ee64806fc4 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 b75f8bef5a8865e893c44cae0cc8d43741e73425 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 9 Jun 2020 17:58:22 -0400 Subject: [PATCH 1047/2516] add the ARM notification group (#740) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/notification-groups/arm.md | 23 +++++++++++++++++++ 2 files changed, 24 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/notification-groups/arm.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index a86eedd6c20f5..36048f7cbb9bc 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/notification-groups/arm.md b/src/doc/rustc-dev-guide/src/notification-groups/arm.md new file mode 100644 index 0000000000000..0b0d21776aa3d --- /dev/null +++ b/src/doc/rustc-dev-guide/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 376f3045d48cba302d10136cede674f7b2cb0c23 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 8 Jun 2020 13:27:16 -0400 Subject: [PATCH 1048/2516] complete the ICE-breaker => notification group rename --- .../src/notification-groups/about.md | 44 ++++++++++--------- 1 file changed, 23 insertions(+), 21 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/notification-groups/about.md b/src/doc/rustc-dev-guide/src/notification-groups/about.md index d9c724532a6e9..f95236aad34e0 100644 --- a/src/doc/rustc-dev-guide/src/notification-groups/about.md +++ b/src/doc/rustc-dev-guide/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 a9241928033cccb6dfdc64753b9d8a0e1993b54a Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 10 Jun 2020 20:19:59 +0200 Subject: [PATCH 1049/2516] Include "Lint" in the title of the diagnostics chapter (#742) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 36048f7cbb9bc..ecc11350c2f36 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 428688fd3beab..ce7a37a79e6ef 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 5fd04061a76f22ebf3297d01796df2dfc8c7bc44 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 10 Jun 2020 15:51:04 -0500 Subject: [PATCH 1050/2516] Only build master branch on push --- src/doc/rustc-dev-guide/.travis.yml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 3e5febe301dbb..582615c4bc6b2 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 089823a8b5610530dde07a5cc6176785af56d823 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Thu, 11 Jun 2020 00:04:19 +0200 Subject: [PATCH 1051/2516] 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 --- .../rustc-dev-guide/src/notification-groups/about.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/notification-groups/about.md b/src/doc/rustc-dev-guide/src/notification-groups/about.md index f95236aad34e0..02ceb92713f51 100644 --- a/src/doc/rustc-dev-guide/src/notification-groups/about.md +++ b/src/doc/rustc-dev-guide/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 a8d4f96e0e04b17265ba4a8db0b734454dc87030 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 10 Jun 2020 21:48:02 -0500 Subject: [PATCH 1052/2516] Fix CI rebase (#745) * Fix CI rebase --- src/doc/rustc-dev-guide/.travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 582615c4bc6b2..58ed7c5621406 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 ebc5658dec66b5329d1f0ef21f0b167f5bae21e7 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 11 Jun 2020 12:38:42 +0200 Subject: [PATCH 1053/2516] tag/niche terminology (#747) --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index f8042170c0832..0a7568992e95a 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 20f701d36a7c2dc6b5fdc946360b8d206ec8dbc2 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 16 Jun 2020 20:23:26 -0700 Subject: [PATCH 1054/2516] Add some more detail on compiletest normalization. --- src/doc/rustc-dev-guide/src/tests/adding.md | 60 ++++++++++++++++----- 1 file changed, 47 insertions(+), 13 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 1df17ae01199d..538860f656080 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 92058c80a61f28b0e7ee02d675b8b6d27cc84660 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 17 Jun 2020 09:52:39 -0400 Subject: [PATCH 1055/2516] Document rustdoc behavior - `RUSTDOC_LOG` - `// aux-build:filename.rs` - `// build-aux-docs` --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 8 ++++++++ src/doc/rustc-dev-guide/src/rustdoc.md | 8 ++++++++ 2 files changed, 16 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index a499224ae1097..0bb3cd1ddd6a4 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index fc964b18e3da2..120ebe139720d 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 b599b68ab541e6410b9308a840686dc436a522f5 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 17 Jun 2020 11:01:46 -0400 Subject: [PATCH 1056/2516] 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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 16d3e14623f04..18b7d1977ef45 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 792d2557a8925712ed447649daff3ed6b97e4293 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 18 Jun 2020 01:33:15 -0700 Subject: [PATCH 1057/2516] Add a link to the forge procedure on adding new options. (#754) --- src/doc/rustc-dev-guide/src/cli.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/cli.md b/src/doc/rustc-dev-guide/src/cli.md index bbb7bae24c5f0..f47c89e1f9b79 100644 --- a/src/doc/rustc-dev-guide/src/cli.md +++ b/src/doc/rustc-dev-guide/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 3fce518c5f6e47c7cff1e6a30dd0246d8e4d8e1e Mon Sep 17 00:00:00 2001 From: mark Date: Mon, 1 Jun 2020 21:58:37 -0500 Subject: [PATCH 1058/2516] start a getting started guide --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../rustc-dev-guide/src/getting-started.md | 223 ++++++++++++++++++ 2 files changed, 224 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/getting-started.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index ecc11350c2f36..f462817c036a1 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md new file mode 100644 index 0000000000000..c829644632811 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 964260df25f0042e355e34c39fe6d3ae1caed45e Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 2 Jun 2020 13:29:06 -0500 Subject: [PATCH 1059/2516] Typo fixes Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/doc/rustc-dev-guide/src/getting-started.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index c829644632811..3c4a541a919d2 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 e7a6fb2de4ee4a491182129df014aba9623e2c7d Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 13:44:20 -0500 Subject: [PATCH 1060/2516] address some review comments --- src/doc/rustc-dev-guide/src/getting-started.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 3c4a541a919d2..bc8d6648a72be 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 d90d6075bfe5c9480a1cb30414b2255c455b6252 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 14:25:30 -0500 Subject: [PATCH 1061/2516] write about processes --- .../rustc-dev-guide/src/getting-started.md | 108 +++++++++++++++++- 1 file changed, 102 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index bc8d6648a72be..1ec7b1b2654e9 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 02975c0d47aac0da3e93405a4787cb75e88a6882 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 14:45:37 -0500 Subject: [PATCH 1062/2516] some minor updates --- src/doc/rustc-dev-guide/src/getting-started.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 1ec7b1b2654e9..4207fd1eec7e4 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 f592f6f9007a2724837197bdaec93374b6feca27 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 14:57:37 -0500 Subject: [PATCH 1063/2516] a couple more small changes --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/getting-started.md | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index f462817c036a1..4f818fadf2c81 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 4207fd1eec7e4..5d78e416bdbb5 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 74ee00932e8f82cddc01434aacb5ec229f025c97 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 19:28:36 -0500 Subject: [PATCH 1064/2516] mention incremental disk space --- src/doc/rustc-dev-guide/src/getting-started.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 5d78e416bdbb5..3c3781da8800f 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 cee0be6ad4dae61f94d747e8165fa988dd21e995 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 19:53:54 -0500 Subject: [PATCH 1065/2516] fix link --- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 3c3781da8800f..9fa76817a44ff 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 8cf37d29d5aad56c6a989a5691c846b135195346 Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 5 Jun 2020 11:24:47 -0500 Subject: [PATCH 1066/2516] add a bit more --- .../rustc-dev-guide/src/getting-started.md | 66 +++++++++++++++++-- 1 file changed, 62 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 9fa76817a44ff..2d11edf8e0a24 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 286f8bcd7ac3604f126fbf7d09f25c1ff6ee8daa Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 5 Jun 2020 11:25:48 -0500 Subject: [PATCH 1067/2516] add note on submodules --- src/doc/rustc-dev-guide/src/getting-started.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 2d11edf8e0a24..d5a4c51b3941f 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 20b62e9c51cda2364c63f5e0e0b9d8dae2341b25 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 5 Jun 2020 11:29:03 -0500 Subject: [PATCH 1068/2516] Apply suggestions from code review Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/doc/rustc-dev-guide/src/getting-started.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index d5a4c51b3941f..21f52ca9c0d2e 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 7ae1067f695eee2ba644f65b9bd3b648a43c6813 Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 5 Jun 2020 11:28:36 -0500 Subject: [PATCH 1069/2516] add forge --- src/doc/rustc-dev-guide/src/getting-started.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 21f52ca9c0d2e..dfc0a843c28c0 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 75338b781af91c67afb37c4d4caca64173949939 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 17 Jun 2020 12:51:41 -0500 Subject: [PATCH 1070/2516] 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 --- .../rustc-dev-guide/src/getting-started.md | 30 +++++++++++++++---- 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index dfc0a843c28c0..d7d7f931442e6 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 ecae3b8e39008d145f5bceb28906db42e5f093cc Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 17 Jun 2020 12:53:46 -0500 Subject: [PATCH 1071/2516] python 3 also --- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index d7d7f931442e6..9715403e6669f 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 84d3fe3f9c63b48bd215dfc4b3b3becf626ac69b Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 17 Jun 2020 12:56:57 -0500 Subject: [PATCH 1072/2516] add a note about disk space --- src/doc/rustc-dev-guide/src/getting-started.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 9715403e6669f..755034cf2b5a3 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 c9a3d20260ce0c8699de3e0dd3a31e99c2eb9cdd Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 17 Jun 2020 13:45:55 -0500 Subject: [PATCH 1073/2516] Slightly reorganize to first present the slow command then the fast commands --- .../rustc-dev-guide/src/getting-started.md | 103 +++++++++++++----- 1 file changed, 74 insertions(+), 29 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 755034cf2b5a3..46639457728d2 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 5e109f15e7f8e6f55c9181179553218992b434e9 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 17 Jun 2020 14:47:47 -0500 Subject: [PATCH 1074/2516] Better wording Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 46639457728d2..cb87210ad7d5a 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 77625450378050674f22150edee2c1e452cd5715 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 17 Jun 2020 17:08:42 -0500 Subject: [PATCH 1075/2516] Apply suggestions from code review Co-authored-by: LeSeulArtichaut --- src/doc/rustc-dev-guide/src/getting-started.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index cb87210ad7d5a..e7c270079663a 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 024c66a2c6b9fb01465556cb03cce79bd290f55a Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 17 Jun 2020 17:18:34 -0500 Subject: [PATCH 1076/2516] address review comments --- .../rustc-dev-guide/src/getting-started.md | 41 +++++++++++-------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index e7c270079663a..b1ed6bc0e5734 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 ec6e0cd899b0a3cf5b2cbbda8df3293cf13e09f4 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 18 Jun 2020 11:55:58 -0500 Subject: [PATCH 1077/2516] LeSeulArtichaut wording/typo fixes Co-authored-by: LeSeulArtichaut --- src/doc/rustc-dev-guide/src/getting-started.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index b1ed6bc0e5734..628326763bd02 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 9788e60daece424aee87b5a9192dc5a69b680f87 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 18 Jun 2020 12:09:50 -0500 Subject: [PATCH 1078/2516] address a bunch of review comments --- .../rustc-dev-guide/src/getting-started.md | 35 ++++++++++++++++--- 1 file changed, 31 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 628326763bd02..5dc9f4d71aaa5 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 3a87c5c07403c08a8c8435621c8cce8a18d35fa2 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 18 Jun 2020 12:11:43 -0500 Subject: [PATCH 1079/2516] fix line length --- src/doc/rustc-dev-guide/src/getting-started.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 5dc9f4d71aaa5..4cd9972007949 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 d8cd89604270aee09c19fdfd063e41cb57698f1b Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 19 Jun 2020 00:55:58 -0500 Subject: [PATCH 1080/2516] new tykind::error convention (#715) --- src/doc/rustc-dev-guide/src/ty.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 6197a22be8ff4..c6affe75ac791 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 af0b2b5735c6fbeb601bb2db7c5267b6d1b98953 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 21 Jun 2020 13:25:43 -0500 Subject: [PATCH 1081/2516] 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 --- src/doc/rustc-dev-guide/.travis.yml | 2 +- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/building/prerequisites.md | 3 +++ src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 4 files changed, 6 insertions(+), 2 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/building/prerequisites.md diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 58ed7c5621406..d375fe9d60016 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 4f818fadf2c81..c900070a44c2b 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md new file mode 100644 index 0000000000000..aa13c7524b55a --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 4cd9972007949..a848b0b754434 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 7822855886a937a8dd2ec74c3dce32554b1135f3 Mon Sep 17 00:00:00 2001 From: ThePuzzlemaker Date: Wed, 10 Jun 2020 21:43:01 -0500 Subject: [PATCH 1082/2516] 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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 18b7d1977ef45..586fa3a2d0cd8 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 784bf0ffb9916ad5389e9f67f8233c2d5081a5c9 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 22 Jun 2020 22:48:15 -0500 Subject: [PATCH 1083/2516] Fix links for now. --- src/doc/rustc-dev-guide/src/appendix/background.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/background.md b/src/doc/rustc-dev-guide/src/appendix/background.md index fe69f6bfda689..983f028a07899 100644 --- a/src/doc/rustc-dev-guide/src/appendix/background.md +++ b/src/doc/rustc-dev-guide/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 41b9022652ea63216281efeb213feabc5df88dcc Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 22 Jun 2020 22:54:14 -0500 Subject: [PATCH 1084/2516] whitelist amazon --- src/doc/rustc-dev-guide/book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index c342c38748ffa..4b029127e4021 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 973ebaa7c76344aabd3a2410a44e4020cb1cf2cb Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 18 Jun 2020 18:35:52 -0500 Subject: [PATCH 1085/2516] fix the rebase trick --- src/doc/rustc-dev-guide/.travis.yml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index d375fe9d60016..634d73871a695 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 8c22955d87ccf08af4f0b873eebec2d9f6d2ec25 Mon Sep 17 00:00:00 2001 From: Andy Russell Date: Tue, 23 Jun 2020 09:36:44 -0400 Subject: [PATCH 1086/2516] 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/doc/rustc-dev-guide/src/diagnostics.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index ce7a37a79e6ef..80ab1306cd52d 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 5fefd83bd133e9893a9aa6e243766aedd391115e Mon Sep 17 00:00:00 2001 From: Florian Gilcher Date: Wed, 27 May 2020 23:20:18 +0200 Subject: [PATCH 1087/2516] Add prerequisite page --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/building/prerequisites.md | 28 ++++++++++++++++++- 2 files changed, 28 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index c900070a44c2b..b7439d0eaf47d 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index aa13c7524b55a..9db18778d39f9 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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 de85be491f9e14964a354fc1c720536aac44ef88 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 18 Jun 2020 12:35:15 -0500 Subject: [PATCH 1088/2516] address review comments --- .../src/building/prerequisites.md | 37 ++++++++++++++++--- 1 file changed, 32 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index 9db18778d39f9..3224c6dab648d 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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 ab42a922a76b3ad63a90b917b6db53472242b74f Mon Sep 17 00:00:00 2001 From: Drew Youngwerth Date: Thu, 18 Jun 2020 16:08:57 -0600 Subject: [PATCH 1089/2516] Small spelling fix. --- src/doc/rustc-dev-guide/src/name-resolution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index d08fe43f3caed..917f792a45784 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 903bc9cd27e1e929f58a1411fb67d82fc8e23344 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 17 Jun 2020 11:04:30 -0400 Subject: [PATCH 1090/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index b7439d0eaf47d..bdfa4aac8e443 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 1b7f28b287bd1367946b90c2afd1dd814ed62731 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 23 Jun 2020 17:40:35 -0400 Subject: [PATCH 1091/2516] Split up rustdoc page --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../rustc-dev-guide/src/rustdoc-internals.md | 197 ++++++++++++++++++ src/doc/rustc-dev-guide/src/rustdoc.md | 193 +---------------- 3 files changed, 200 insertions(+), 191 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/rustdoc-internals.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index bdfa4aac8e443..d8091965797c6 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md new file mode 100644 index 0000000000000..59cee9f1c44e7 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 120ebe139720d..0e80c069941c7 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 c78b9831cb95f2e5597e67e21c8282e3856d6bfc Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 23 Jun 2020 17:53:09 -0400 Subject: [PATCH 1092/2516] Move x.py commands to overview --- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 3 --- src/doc/rustc-dev-guide/src/rustdoc.md | 6 +++++- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index 59cee9f1c44e7..ab3bf1b3011f2 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 0e80c069941c7..6ac944697ad75 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 4d0935f6769ebe17dc02ceba811ab37f8b2dc353 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 24 Jun 2020 12:47:50 -0500 Subject: [PATCH 1093/2516] 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 --- src/doc/rustc-dev-guide/.travis.yml | 4 +- src/doc/rustc-dev-guide/src/SUMMARY.md | 255 +++++++++--------- .../rustc-dev-guide/src/about-this-guide.md | 12 +- src/doc/rustc-dev-guide/src/part-1-intro.md | 7 - 4 files changed, 144 insertions(+), 134 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/part-1-intro.md diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 634d73871a695..4a78953cb3608 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index d8091965797c6..f57ba4f23e333 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 58b0cb9f0c7bf..dfe14d2245928 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-1-intro.md b/src/doc/rustc-dev-guide/src/part-1-intro.md deleted file mode 100644 index 95d2f8fccf1d2..0000000000000 --- a/src/doc/rustc-dev-guide/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 06b19cc2230c4b84e3e43137728342b2be1fedb4 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 24 Jun 2020 13:22:30 -0500 Subject: [PATCH 1094/2516] Fix formatting --- src/doc/rustc-dev-guide/src/building/prerequisites.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index 3224c6dab648d..f4b0a92a4e042 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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 3707d2039bb2ea132ecbe54cefcd9ac5ca264fe3 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 24 Jun 2020 13:11:27 -0500 Subject: [PATCH 1095/2516] Fold chapters by default to make ToC shorter --- src/doc/rustc-dev-guide/book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 4b029127e4021..1e1c54cc99a7c 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 6e54283cdc0eb94d3b5833f8237b1fa7496c3bcd Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Sat, 27 Jun 2020 11:47:47 -0400 Subject: [PATCH 1096/2516] Add 'recovery' to the gloassary --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 0a7568992e95a..f428c8f0b69cb 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 9a6bd527e64f95423836347385575f826a29a594 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 23 Jun 2020 15:54:01 -0400 Subject: [PATCH 1097/2516] 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/doc/rustc-dev-guide/src/overview.md | 30 +++---- 2 files changed, 88 insertions(+), 20 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 5ba8ef88d3754..536a4118f0e2a 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 37e82822d7b6b..9594bab535eba 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 ff7b681fdfcfc6b8a2e9d1080ed95d6037fd6674 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 23 Jun 2020 19:20:42 -0400 Subject: [PATCH 1098/2516] Improve wording and fix typos Co-authored-by: Who? Me?! --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 536a4118f0e2a..843cc2641525f 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 187ec0a233b8d971886b73c14a32ed8e73d8b603 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 23 Jun 2020 20:46:31 -0400 Subject: [PATCH 1099/2516] Fix line lengths --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 843cc2641525f..e7a0315221e68 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 b0e4026c89f0b959629086a5586931fa97b3a26c Mon Sep 17 00:00:00 2001 From: pierwill Date: Sat, 27 Jun 2020 16:08:48 -0700 Subject: [PATCH 1100/2516] Edit ty.md Makes various edits throughout for formatting, punctuation, and typo fixes. Also makes some edits and re-wording for clarity. --- src/doc/rustc-dev-guide/src/ty.md | 85 +++++++++++++++---------------- 1 file changed, 40 insertions(+), 45 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index c6affe75ac791..2587f61bace96 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 f88a71e05fd4f9024f6f8515874762971026b9d2 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 30 Jun 2020 23:22:38 +0900 Subject: [PATCH 1101/2516] Rename resolvers following the latest rustc change (#776) --- src/doc/rustc-dev-guide/src/macro-expansion.md | 4 ++-- src/doc/rustc-dev-guide/src/name-resolution.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 7961d0cf1262e..1b06cab417337 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 917f792a45784..dfea5f22c46f4 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 51dcf86470bb4575685de8442288289e5e47c9b5 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 24 Jun 2020 13:15:29 -0500 Subject: [PATCH 1102/2516] Move Errors and Lints to Analysis --- src/doc/rustc-dev-guide/src/SUMMARY.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index f57ba4f23e333..21f642a08d4a8 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 92f89b8b220f6ebda11ed9d03afb946801a1acf1 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 24 Jun 2020 13:20:12 -0500 Subject: [PATCH 1103/2516] Move Getting Started to a "prefix chapter" --- src/doc/rustc-dev-guide/src/SUMMARY.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 21f642a08d4a8..31a2259f9b950 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 29d58844e570236955f6bda9c455aa8d58141b3c Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 27 Jun 2020 12:42:26 -0500 Subject: [PATCH 1104/2516] fix file name --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- .../src/{codegen => backend}/implicit-caller-location.md | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename src/doc/rustc-dev-guide/src/{codegen => backend}/implicit-caller-location.md (100%) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 31a2259f9b950..4edb25d428d3f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md b/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md similarity index 100% rename from src/doc/rustc-dev-guide/src/codegen/implicit-caller-location.md rename to src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md From c601b98e9984ac6404f220a3bc22d911922d7816 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 1105/2516] Edit Part 2 introduction (#777) * Edit Part 2 introduction * needs a pause Co-authored-by: Tshepang Lekhonkhobe --- src/doc/rustc-dev-guide/src/part-2-intro.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/part-2-intro.md b/src/doc/rustc-dev-guide/src/part-2-intro.md index 04ae3f955b95f..5ea4d7b6b6fef 100644 --- a/src/doc/rustc-dev-guide/src/part-2-intro.md +++ b/src/doc/rustc-dev-guide/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 1bf5785b54f37f25ac492392cf7c41a52f731a79 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 17 Jun 2020 14:38:39 -0500 Subject: [PATCH 1106/2516] move CONTRIBUTING.md to rustc-dev-guide --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/contributing.md | 499 ++++++++++++++++++++ 2 files changed, 500 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/contributing.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 4edb25d428d3f..5a1dcc68e5ba0 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md new file mode 100644 index 0000000000000..e2bce693aff4b --- /dev/null +++ b/src/doc/rustc-dev-guide/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 5dd54768de000d6daf14f0b9e8548dd065122be8 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 23 Jun 2020 12:51:07 -0500 Subject: [PATCH 1107/2516] line length --- src/doc/rustc-dev-guide/src/contributing.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index e2bce693aff4b..017f0c2aef3ca 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 cf096d7b815aeb4bc6b51ffa93e26f2a498be917 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 23 Jun 2020 12:57:15 -0500 Subject: [PATCH 1108/2516] fix links --- src/doc/rustc-dev-guide/src/contributing.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 017f0c2aef3ca..f6368c607a817 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 aec5f9636d344ae7eb13160d6b239ea8c93e976c Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 23 Jun 2020 12:59:05 -0500 Subject: [PATCH 1109/2516] fix links --- src/doc/rustc-dev-guide/src/contributing.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index f6368c607a817..d4dfc5a0bb358 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 05ae9fdff4edf409270ba2a51d0457585f3dedd0 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 23 Jun 2020 20:59:35 -0500 Subject: [PATCH 1110/2516] Fix non-link Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index d4dfc5a0bb358..3959e14ed7e47 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 6d037786794e625fba264536a52f75c22aa02edf Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 23 Jun 2020 22:52:33 -0500 Subject: [PATCH 1111/2516] Escape other non-link Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 3959e14ed7e47..3cadde8228759 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 afa134b09fabb419da3cbfcd016edada1056791f Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 1 Jul 2020 21:42:05 -0500 Subject: [PATCH 1112/2516] fix links --- src/doc/rustc-dev-guide/src/contributing.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 3cadde8228759..0667e5339ee8e 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 2b56a22b3f7fa48b9c478d83993e9f8662346b1a Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Thu, 2 Jul 2020 23:28:32 +0900 Subject: [PATCH 1113/2516] 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/doc/rustc-dev-guide/src/appendix/background.md | 2 +- src/doc/rustc-dev-guide/src/appendix/code-index.md | 2 +- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/background.md b/src/doc/rustc-dev-guide/src/appendix/background.md index 983f028a07899..e7b9f3afc1493 100644 --- a/src/doc/rustc-dev-guide/src/appendix/background.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 76f4609cc81a8..8561efe4c0e92 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index f428c8f0b69cb..9e8703d1bb36e 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/src/appendix/glossary.md @@ -1,4 +1,4 @@ -# Appendix C: Glossary +# Glossary Term | Meaning -----------------------------------------|-------- From 996d9c6e89def2869ca41d98a479beab6be2a6f4 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 2 Jul 2020 17:37:29 -0500 Subject: [PATCH 1114/2516] add stub inline asm chapter (#773) --- src/doc/rustc-dev-guide/src/backend/inline-asm.md | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/backend/inline-asm.md diff --git a/src/doc/rustc-dev-guide/src/backend/inline-asm.md b/src/doc/rustc-dev-guide/src/backend/inline-asm.md new file mode 100644 index 0000000000000..0cae01ef3957f --- /dev/null +++ b/src/doc/rustc-dev-guide/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 f3acc902d5d3e1b179cf3ac46958b9c4f340914d Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 3 Jul 2020 08:28:44 -0700 Subject: [PATCH 1115/2516] Minor updates to stage docs. (#781) --- .../src/building/bootstrapping.md | 20 +++++++++---------- .../src/building/how-to-build-and-run.md | 9 +++++---- .../rustc-dev-guide/src/img/rustc_stages.svg | 3 ++- 3 files changed, 17 insertions(+), 15 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index e7a0315221e68..cce9fac49a402 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 586fa3a2d0cd8..f9ce3f73476cd 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/img/rustc_stages.svg b/src/doc/rustc-dev-guide/src/img/rustc_stages.svg index b6671aa7cc4b2..25f7ab11b47ab 100644 --- a/src/doc/rustc-dev-guide/src/img/rustc_stages.svg +++ b/src/doc/rustc-dev-guide/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 7dede8417946e88c964eab67637e12d96cb0855e Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Sat, 4 Jul 2020 00:31:52 +0900 Subject: [PATCH 1116/2516] Fix jump marker of debruijn index (#783) --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 9e8703d1bb36e..748f4feb57111 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 dd3f003fd210a83fcf9b862f89d8783f5bf15b40 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 3 Jul 2020 09:56:05 -0700 Subject: [PATCH 1117/2516] Update mdbook --- src/doc/rustc-dev-guide/.travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 4a78953cb3608..a217f1cacb9e1 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 8a640ae662e9e3343f8471b0016f414662d1f262 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 2 Jul 2020 22:35:47 -0700 Subject: [PATCH 1118/2516] Update docs on using Docker images. --- src/doc/rustc-dev-guide/src/tests/intro.md | 50 +++++++++++++++++++--- 1 file changed, 44 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 2fa1363d0adeb..b772da011027b 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 f266ef6d85d5aaa2661e7f604acab74e37726111 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 5 Jul 2020 02:40:39 +0900 Subject: [PATCH 1119/2516] Fix link for armhf-gnu Dockerfile --- src/doc/rustc-dev-guide/src/tests/intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index b772da011027b..0f517f8712bbb 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 ac0e09998d8dce7adea4937d09ca43c3090be1e9 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sat, 4 Jul 2020 10:22:29 -0700 Subject: [PATCH 1120/2516] Update bug report links. --- src/doc/rustc-dev-guide/src/contributing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 0667e5339ee8e..8e0eebb70eda2 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 f571c63e0170e271a9ecc5eace1464c6c6b75c7f Mon Sep 17 00:00:00 2001 From: Nadrieril Date: Thu, 2 Jul 2020 22:16:34 +0100 Subject: [PATCH 1121/2516] Suggest selectively disabling optimizations --- .../rustc-dev-guide/src/building/suggested.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 4491a3b7233f5..102586721d0db 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 00e7637fdd4c50e30cccc1347e2ac19305f67a74 Mon Sep 17 00:00:00 2001 From: Matt Kraai Date: Sat, 4 Jul 2020 23:19:10 +0000 Subject: [PATCH 1122/2516] Canonicalize part 1 name (#788) --- src/doc/rustc-dev-guide/src/about-this-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index dfe14d2245928..11b0876a94c7d 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 19afa0dcb92c501613a9f92748ff5c7b95c41ff5 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 10 Jul 2020 18:14:16 -0300 Subject: [PATCH 1123/2516] inluding -> including --- src/doc/rustc-dev-guide/src/about-this-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 11b0876a94c7d..77dbf26991f3c 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 31b0ea720a6645c161d159dc36cdc6c68ffc0103 Mon Sep 17 00:00:00 2001 From: Ivan Veselov Date: Sat, 11 Jul 2020 15:25:04 +0100 Subject: [PATCH 1124/2516] Fix typo: review -> reviewer --- src/doc/rustc-dev-guide/src/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index c74f72cc571bf..c2a1308b6bb51 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 8ab8ba4e9b31c5b1b21bc9086216d2c4a5725aba Mon Sep 17 00:00:00 2001 From: Ivan Veselov Date: Sun, 12 Jul 2020 02:29:17 +0100 Subject: [PATCH 1125/2516] Earlier clarification of pFCP abbreviation (#791) --- .../src/implementing_new_features.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 686c9b27044cf..233d223dbbb46 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 6291aa68cb6f9282738977fe1fc536ee0e378c11 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Tue, 14 Jul 2020 10:06:22 +0900 Subject: [PATCH 1126/2516] Fix the difference of title in appendix A (#793) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 5a1dcc68e5ba0..4f1c73293d728 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 c6ea7719aa8d4d788e2e1dce7b016d200f705c14 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sat, 11 Jul 2020 15:50:34 -0400 Subject: [PATCH 1127/2516] 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 --- .../rustc-dev-guide/src/getting-started.md | 30 +++++++++++-------- 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index a848b0b754434..9d5c86a039cde 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 4c67ee9268080c528a6cb232cb60a87f772624b2 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 14 Jul 2020 16:20:30 +0900 Subject: [PATCH 1128/2516] Fix distortions of "representation" --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/part-3-intro.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 4f1c73293d728..53e75fc09f0a9 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-3-intro.md b/src/doc/rustc-dev-guide/src/part-3-intro.md index 2af8cce23e22e..c10080632888b 100644 --- a/src/doc/rustc-dev-guide/src/part-3-intro.md +++ b/src/doc/rustc-dev-guide/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 4462ce21a166da7b712ac072967fd37b564f4da3 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 14 Jul 2020 16:20:44 +0900 Subject: [PATCH 1129/2516] Fix typos --- src/doc/rustc-dev-guide/src/backend/backend-agnostic.md | 4 ++-- src/doc/rustc-dev-guide/src/backend/debugging.md | 2 +- .../rustc-dev-guide/src/backend/implicit-caller-location.md | 2 +- src/doc/rustc-dev-guide/src/backend/lowering-mir.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md index 209df0afa3bc0..d0984feec921c 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/debugging.md b/src/doc/rustc-dev-guide/src/backend/debugging.md index 06e62d9ec0eee..f8ea4f5ed0eb6 100644 --- a/src/doc/rustc-dev-guide/src/backend/debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/implicit-caller-location.md b/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md index c6dc89f650af2..e0a12415ec7d7 100644 --- a/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/lowering-mir.md b/src/doc/rustc-dev-guide/src/backend/lowering-mir.md index 93516c5d87f18..2ab15e6f8c46a 100644 --- a/src/doc/rustc-dev-guide/src/backend/lowering-mir.md +++ b/src/doc/rustc-dev-guide/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 bbf5425613060685936c625941e5c5ec519e04bc Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 14 Jul 2020 11:08:43 -0300 Subject: [PATCH 1130/2516] 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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index f9ce3f73476cd..155c84972666f 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 b42b4108894fa2ec92d3dec78c68a97366afd443 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Thu, 16 Jul 2020 11:13:49 +0900 Subject: [PATCH 1131/2516] Change `rustc::*` to `rustc_middle::*` (#798) --- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics/lintstore.md | 12 ++++++------ src/doc/rustc-dev-guide/src/memory.md | 2 +- src/doc/rustc-dev-guide/src/mir/visitor.md | 4 ++-- src/doc/rustc-dev-guide/src/overview.md | 4 ++-- src/doc/rustc-dev-guide/src/ty.md | 4 ++-- 6 files changed, 14 insertions(+), 14 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 80ab1306cd52d..432ea89037074 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index b0ae9a328756c..2942dac027ad0 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/memory.md b/src/doc/rustc-dev-guide/src/memory.md index 43b3746f00e0d..cde2f454c5c9c 100644 --- a/src/doc/rustc-dev-guide/src/memory.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/visitor.md b/src/doc/rustc-dev-guide/src/mir/visitor.md index a0d38ca0b660b..c80462b953f0d 100644 --- a/src/doc/rustc-dev-guide/src/mir/visitor.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 9594bab535eba..15946edc41ae5 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 2587f61bace96..d1e2750c11a18 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 88013f3fb890bf5cd44170b614248404b150ca21 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 17 Jul 2020 01:53:43 +0900 Subject: [PATCH 1132/2516] Exclude `rustaceans.org` from linkcheck --- src/doc/rustc-dev-guide/book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 1e1c54cc99a7c..10bc2edd488fa 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 3133f81eb1b998cf5059d1eea31f19eac915b3a1 Mon Sep 17 00:00:00 2001 From: Felix S Klock II Date: Fri, 17 Jul 2020 00:01:31 -0400 Subject: [PATCH 1133/2516] Update chat info to reflect decision to close down Discord `#compiler`. (#800) Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/compiler-team.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index 3f3719f3df109..33ff65af604d0 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 850d719f29732d9dce888b8f94442aaa20c97694 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 18 Jul 2020 00:00:34 +0900 Subject: [PATCH 1134/2516] Clean-up minor issues (#802) --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 4 ++-- src/doc/rustc-dev-guide/src/contributing.md | 2 +- src/doc/rustc-dev-guide/src/getting-started.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 0bb3cd1ddd6a4..0c40d63e48f4d 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 8e0eebb70eda2..ec94a3f9c6338 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 9d5c86a039cde..a2994a4bee3a0 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 f4056d677264b445e1e2c5fa527e9cff7ad12f1c Mon Sep 17 00:00:00 2001 From: Federico Ponzi Date: Sat, 18 Jul 2020 12:18:06 +0200 Subject: [PATCH 1135/2516] Fixes menu for rustdoc page (#804) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 53e75fc09f0a9..b856afe74c4e8 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 3465a519a701e9c34c043b4ad1eda43ab9bc1470 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 22 Jul 2020 19:32:21 +0900 Subject: [PATCH 1136/2516] Fix links for cranelift (#809) --- src/doc/rustc-dev-guide/src/backend/backend-agnostic.md | 2 +- src/doc/rustc-dev-guide/src/backend/codegen.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md index d0984feec921c..07914b847e7ba 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/codegen.md b/src/doc/rustc-dev-guide/src/backend/codegen.md index d7bad9cfbbaa9..5db9b2b05c182 100644 --- a/src/doc/rustc-dev-guide/src/backend/codegen.md +++ b/src/doc/rustc-dev-guide/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 b6c83c25578b99b0068958962222f1befae8ec50 Mon Sep 17 00:00:00 2001 From: David Wood Date: Wed, 22 Jul 2020 11:42:50 +0100 Subject: [PATCH 1137/2516] 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 --- .../rustc-dev-guide/src/backend/monomorph.md | 82 ++++++++++++++----- 1 file changed, 61 insertions(+), 21 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index 5e5d2e0c492c5..47b41d4f6c9f9 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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 c276f8a91a7f5d4249a9ea7f204aaf1a4781315f Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 25 Jul 2020 04:46:33 +0900 Subject: [PATCH 1138/2516] Turn off travis' email notifications --- src/doc/rustc-dev-guide/.travis.yml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index a217f1cacb9e1..304abbf8f7129 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 1488e6b613de678ad709dad233a0c93e5b42cdbe Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 27 Jul 2020 17:03:37 -0300 Subject: [PATCH 1139/2516] Fix MIR to LLVM IR sentence (#811) --- src/doc/rustc-dev-guide/src/overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 15946edc41ae5..eb774b11338db 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 01c4ec6593b26ffc8b8ab4d849fe63bb661f9bb3 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 29 Jul 2020 02:06:07 +0900 Subject: [PATCH 1140/2516] 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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/notification-groups/risc-v.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index b856afe74c4e8..db2155cb8fea2 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/notification-groups/about.md b/src/doc/rustc-dev-guide/src/notification-groups/about.md index 02ceb92713f51..260c59c24c449 100644 --- a/src/doc/rustc-dev-guide/src/notification-groups/about.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/notification-groups/arm.md b/src/doc/rustc-dev-guide/src/notification-groups/arm.md index 0b0d21776aa3d..4514f8ef39844 100644 --- a/src/doc/rustc-dev-guide/src/notification-groups/arm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/notification-groups/risc-v.md b/src/doc/rustc-dev-guide/src/notification-groups/risc-v.md new file mode 100644 index 0000000000000..15ce1cfc6e6cf --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/notification-groups/windows.md b/src/doc/rustc-dev-guide/src/notification-groups/windows.md index 328ee64806fc4..0483babd83015 100644 --- a/src/doc/rustc-dev-guide/src/notification-groups/windows.md +++ b/src/doc/rustc-dev-guide/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 f56cc073d53c4a8698afbebb387df662587f246f Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 28 Jul 2020 15:20:00 -0400 Subject: [PATCH 1141/2516] Update docs to match the new x.py defaults (#813) --- src/doc/rustc-dev-guide/README.md | 2 +- .../src/building/compiler-documenting.md | 5 ++- .../src/building/how-to-build-and-run.md | 44 +++++-------------- .../rustc-dev-guide/src/building/suggested.md | 8 ++-- src/doc/rustc-dev-guide/src/contributing.md | 10 ++--- .../rustc-dev-guide/src/getting-started.md | 42 +++++++++--------- .../rustc-dev-guide/src/queries/profiling.md | 2 +- src/doc/rustc-dev-guide/src/rustdoc.md | 4 +- src/doc/rustc-dev-guide/src/tests/running.md | 35 +++++++-------- 9 files changed, 66 insertions(+), 86 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 8f7db233ef477..345b385892ebe 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/compiler-documenting.md b/src/doc/rustc-dev-guide/src/building/compiler-documenting.md index 68c9fd2279f55..111f6858d9f17 100644 --- a/src/doc/rustc-dev-guide/src/building/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 155c84972666f..f4d783f5daf6e 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 102586721d0db..fd2c00baa4170 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index ec94a3f9c6338..180197ddc2fa2 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index a2994a4bee3a0..9d5db4b05d3b1 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index 958dd33376951..33d001f399414 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 6ac944697ad75..1a3cf7019f0c8 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index a6303c1a6fc55..44561f6f2da40 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 89f2a915e2c91f98ef06260a83ec93b072197ed9 Mon Sep 17 00:00:00 2001 From: Jake Goulding Date: Tue, 28 Jul 2020 15:41:28 -0400 Subject: [PATCH 1142/2516] Add basic steps for a new target (#805) Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/building/new-target.md | 101 ++++++++++++++++++ 2 files changed, 102 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/building/new-target.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index db2155cb8fea2..391a32b9e1e1f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md new file mode 100644 index 0000000000000..0bd200908950a --- /dev/null +++ b/src/doc/rustc-dev-guide/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 0b36e3a37f587d69480320057871cf17e0614ed7 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 30 Jul 2020 22:47:22 +0900 Subject: [PATCH 1143/2516] 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 +- .../rustc-dev-guide/src/building/suggested.md | 8 ++-- src/doc/rustc-dev-guide/src/contributing.md | 2 +- .../rustc-dev-guide/src/getting-started.md | 14 +++--- .../src/panic-implementation.md | 43 ++++++++++--------- .../src/profile-guided-optimization.md | 4 +- .../rustc-dev-guide/src/queries/profiling.md | 2 +- .../rustc-dev-guide/src/rustdoc-internals.md | 2 +- src/doc/rustc-dev-guide/src/rustdoc.md | 4 +- .../src/stabilization_guide.md | 2 +- src/doc/rustc-dev-guide/src/tests/adding.md | 4 +- src/doc/rustc-dev-guide/src/tests/intro.md | 6 +-- src/doc/rustc-dev-guide/src/tests/running.md | 6 +-- src/doc/rustc-dev-guide/src/walkthrough.md | 2 +- 18 files changed, 78 insertions(+), 77 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md b/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md index e0a12415ec7d7..a621b57b110fe 100644 --- a/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index cce9fac49a402..a2eeb6029ebaf 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/compiler-documenting.md b/src/doc/rustc-dev-guide/src/building/compiler-documenting.md index 111f6858d9f17..af3cd7ce289b5 100644 --- a/src/doc/rustc-dev-guide/src/building/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index f4d783f5daf6e..29d10edd096e9 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index 0bd200908950a..eea01e9cc6023 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index fd2c00baa4170..08858507f94d6 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 180197ddc2fa2..e835eef8422ae 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 9d5db4b05d3b1..055551c60ab02 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index 549a9cd05f117..1b4f827d4685b 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profile-guided-optimization.md b/src/doc/rustc-dev-guide/src/profile-guided-optimization.md index fb897e901ef96..03198fb1aa7bb 100644 --- a/src/doc/rustc-dev-guide/src/profile-guided-optimization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index 33d001f399414..8c6050da20db8 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index ab3bf1b3011f2..d44e6679b91a5 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 1a3cf7019f0c8..b37c15808cfe4 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 73edc3be5b469..73875bceb2049 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 538860f656080..c74f6cec4fe86 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 0f517f8712bbb..125e2c931d59b 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 44561f6f2da40..1a6805132492e 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index c2a1308b6bb51..9963692c7987e 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 59d86597ab9b140fa4b44db09b9588d3acbcd86f Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 31 Jul 2020 12:56:11 +0900 Subject: [PATCH 1144/2516] Adjust mentions about CI to GitHub Actions --- src/doc/rustc-dev-guide/README.md | 5 +++- .../src/notification-groups/llvm.md | 2 +- src/doc/rustc-dev-guide/src/tests/intro.md | 24 ++++++++++--------- src/doc/rustc-dev-guide/src/tests/running.md | 6 ++--- src/doc/rustc-dev-guide/src/walkthrough.md | 4 ++-- 5 files changed, 23 insertions(+), 18 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 345b385892ebe..eda6a4565abd0 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/notification-groups/llvm.md b/src/doc/rustc-dev-guide/src/notification-groups/llvm.md index d657231f2d6fd..f1f2097e5f4b1 100644 --- a/src/doc/rustc-dev-guide/src/notification-groups/llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 125e2c931d59b..3503e7ad10b44 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 1a6805132492e..1043f87a19cfa 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 9963692c7987e..8a41b3dd89b19 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 dcc0260d307a43d01e62d5f9e16c0baa312fc086 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 1 Aug 2020 02:05:57 +0900 Subject: [PATCH 1145/2516] Address review comment --- src/doc/rustc-dev-guide/README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index eda6a4565abd0..5dbd5d27f35db 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 1b3d77f1ca3371817a542d56f9ec15b1c59c3819 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 2 Aug 2020 02:33:51 +0900 Subject: [PATCH 1146/2516] Rename `HAIR` to `THIR` --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- .../src/borrow_check/two_phase_borrows.md | 2 +- .../rustc-dev-guide/src/mir/construction.md | 20 +++++++++---------- src/doc/rustc-dev-guide/src/overview.md | 12 +++++------ 4 files changed, 18 insertions(+), 18 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 391a32b9e1e1f..1fe7dcf11af5f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md b/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md index ad17bbb66db69..a5e26c6a88ed3 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index f353eacdf252b..585984e2a1190 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index eb774b11338db..8813d215e4e42 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 352c50122e4d99b716eb0d1210dd0a137ddce1d9 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 2 Aug 2020 09:37:43 +0900 Subject: [PATCH 1147/2516] Mention `HAIR` to clarify --- src/doc/rustc-dev-guide/src/mir/construction.md | 1 + src/doc/rustc-dev-guide/src/overview.md | 8 ++++---- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 585984e2a1190..7fe9ee8840ede 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 8813d215e4e42..ec96d243fb2fa 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 f1c47dc8acbd6fbd9dc3021f63133c4ed112093c Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 24 Jun 2020 11:53:38 -0500 Subject: [PATCH 1148/2516] rewrite/update compiler source code chapter --- src/doc/rustc-dev-guide/src/compiler-src.md | 282 ++++++++++---------- 1 file changed, 147 insertions(+), 135 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 25b3baa3e4579..efb9ae896b75c 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 9cab57e564cb402c077f6c6eec1019e88645797f Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 24 Jun 2020 12:38:44 -0500 Subject: [PATCH 1149/2516] line length --- src/doc/rustc-dev-guide/src/compiler-src.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index efb9ae896b75c..e0789e2a26ff1 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 acf02f063ebe7f49a21b61f31808d2b1dea1e2f2 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 24 Jun 2020 13:24:40 -0500 Subject: [PATCH 1150/2516] fix typo --- src/doc/rustc-dev-guide/src/compiler-src.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index e0789e2a26ff1..27d656eadc489 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 40884cad8507b72b1183710f49a01130daa0f85f Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 26 Jun 2020 19:59:46 -0500 Subject: [PATCH 1151/2516] add a bit more discussion of big picture --- src/doc/rustc-dev-guide/src/compiler-src.md | 55 ++++++++++++++++++--- 1 file changed, 47 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 27d656eadc489..5d8c3ca04dee6 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 d4d856c3b100438b2052bfa7ff4900e2d20eeb6a Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 27 Jun 2020 11:07:25 -0500 Subject: [PATCH 1152/2516] missing link --- src/doc/rustc-dev-guide/src/compiler-src.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 5d8c3ca04dee6..fc71187347a46 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 23f72438e0c32d1d4145fe25a31e7346ac721380 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 20 Jul 2020 19:34:11 -0500 Subject: [PATCH 1153/2516] Link to overview ch instead of internals Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/compiler-src.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index fc71187347a46..67940d367df4b 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 b6554ff04798cc57745560f03a10cefc91a32a6c Mon Sep 17 00:00:00 2001 From: mark Date: Mon, 20 Jul 2020 19:42:01 -0500 Subject: [PATCH 1154/2516] mention the overview chapter --- src/doc/rustc-dev-guide/src/compiler-src.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 67940d367df4b..a9d708f1a8868 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 e05e9b623bef3c170f744078b8be0a456c89aae5 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 24 Jul 2020 18:13:25 -0500 Subject: [PATCH 1155/2516] Typo Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/compiler-src.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index a9d708f1a8868..a976701aa7252 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 c90ba68a2cbd09c032e6d44a99e8e447a156cb53 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 2 Aug 2020 18:45:03 -0500 Subject: [PATCH 1156/2516] some updates after std libs move --- src/doc/rustc-dev-guide/src/compiler-src.md | 47 +++++++++++++-------- 1 file changed, 29 insertions(+), 18 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index a976701aa7252..55eea49e57036 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 0ce72a539ea085f11742408d918f7a0e32d87999 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 2 Aug 2020 19:38:20 -0500 Subject: [PATCH 1157/2516] Typo Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/compiler-src.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 55eea49e57036..df8bc2bd18061 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 2aa21b8d793d8ac71edc14a25080f4c82e88af33 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 3 Aug 2020 10:14:27 +0900 Subject: [PATCH 1158/2516] Fix link/wording for `parse_nt` --- src/doc/rustc-dev-guide/src/overview.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index ec96d243fb2fa..9d8dfd908eecc 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 b71885e14eaf02a46fc821c40ed42e1fdcc1a484 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 3 Aug 2020 11:53:26 +0900 Subject: [PATCH 1159/2516] Prefer `::` than `.` --- src/doc/rustc-dev-guide/src/overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 9d8dfd908eecc..e97fba6b9cc8c 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 43cc8ec16f5eb70c159e394488373047e4ce6a68 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Mon, 3 Aug 2020 22:02:52 +0900 Subject: [PATCH 1160/2516] Fix examples not working --- src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs index 4b0b23aaa52f8..f01072b7beabf 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs index cf08ed87fc30a..e1caab326b7d0 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs index 105ee00194eb3..e33c2ee9571a4 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs +++ b/src/doc/rustc-dev-guide/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 5236330427e39c74d8d4887db6ec048287dcf475 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Mon, 3 Aug 2020 22:06:35 +0900 Subject: [PATCH 1161/2516] Avoid "whitelist" Fixed according to https://github.com/rust-lang/rust/commit/62cf767a4a39b47677d18110359d9e7152dc9d1c --- src/doc/rustc-dev-guide/src/crates-io.md | 10 +++++----- src/doc/rustc-dev-guide/src/stability.md | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/crates-io.md b/src/doc/rustc-dev-guide/src/crates-io.md index 21dd00afe5077..17757454e9ba2 100644 --- a/src/doc/rustc-dev-guide/src/crates-io.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index f48c3d529ddf1..1160ee98d1740 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 07660d0008ec9f2054b89e8ef8fe9f5cf5acafce Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Mon, 3 Aug 2020 22:58:57 +0900 Subject: [PATCH 1162/2516] Fix: crates -> a list of crates --- src/doc/rustc-dev-guide/src/crates-io.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/crates-io.md b/src/doc/rustc-dev-guide/src/crates-io.md index 17757454e9ba2..9e94ba540e02f 100644 --- a/src/doc/rustc-dev-guide/src/crates-io.md +++ b/src/doc/rustc-dev-guide/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 5d4f6c7fbcf040c3e2f5b9288ccc14c75cb74928 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Mon, 3 Aug 2020 23:03:59 +0900 Subject: [PATCH 1163/2516] Fix typo --- src/doc/rustc-dev-guide/src/crates-io.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/crates-io.md b/src/doc/rustc-dev-guide/src/crates-io.md index 9e94ba540e02f..7333bd9b82c42 100644 --- a/src/doc/rustc-dev-guide/src/crates-io.md +++ b/src/doc/rustc-dev-guide/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 bfc15c8e37aaabdc23c958eaca80506b227c7be0 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Mon, 3 Aug 2020 23:32:19 +0900 Subject: [PATCH 1164/2516] Some small fixes --- src/doc/rustc-dev-guide/src/crates-io.md | 3 +-- src/doc/rustc-dev-guide/src/stability.md | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/crates-io.md b/src/doc/rustc-dev-guide/src/crates-io.md index 7333bd9b82c42..6fbabdc914b04 100644 --- a/src/doc/rustc-dev-guide/src/crates-io.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 1160ee98d1740..9255f4b57bc38 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 b93efb7b853a2092308e02f8c48813961fb0095f Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Tue, 4 Aug 2020 22:20:38 +0900 Subject: [PATCH 1165/2516] Enable a link --- .../src/queries/incremental-compilation-in-detail.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index d8716acdfffda..a4e1cd92bb3cc 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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 b4392ae7bf5b4fcc4f888b75c1f26ed9a9646c5b Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Tue, 4 Aug 2020 22:21:19 +0900 Subject: [PATCH 1166/2516] Fix a broken link --- src/doc/rustc-dev-guide/src/parallel-rustc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index add902d3a6dae..0405a947a8624 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 46815eac19518de29e7d52d6596ffa50b9a91f4a Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Tue, 4 Aug 2020 22:26:06 +0900 Subject: [PATCH 1167/2516] Fix typo --- src/doc/rustc-dev-guide/src/name-resolution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index dfea5f22c46f4..cc6eed7f85f51 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 42e8a377a2d6736974f51d7daf4c6420abfd1cf6 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Tue, 4 Aug 2020 22:40:10 +0900 Subject: [PATCH 1168/2516] 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/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index a4e1cd92bb3cc..96255227faa49 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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 41df111b4a2d45da207446f4379d1d1e0f53ce2e Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Wed, 12 Aug 2020 08:36:48 +0900 Subject: [PATCH 1169/2516] Some small fixes (#823) * Fix some typos * Update from `typeck_tables_of` to `typeck` * Fix comment --- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md | 2 +- src/doc/rustc-dev-guide/src/overview.md | 2 +- src/doc/rustc-dev-guide/src/queries/profiling.md | 2 +- .../src/rustc-driver-interacting-with-the-ast.md | 2 +- src/doc/rustc-dev-guide/src/traits/hrtb.md | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 432ea89037074..5ad2fbb329bd0 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md index 0e923c5e1bae1..e0d144bfcf763 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index e97fba6b9cc8c..5bcf26911c1b2 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index 8c6050da20db8..593d0b38547d5 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md b/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md index 0cdc84393c1fb..21d03bbb7403d 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/hrtb.md b/src/doc/rustc-dev-guide/src/traits/hrtb.md index 81391f7ae28e2..c0ca318e6e2d0 100644 --- a/src/doc/rustc-dev-guide/src/traits/hrtb.md +++ b/src/doc/rustc-dev-guide/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 b3f1babc6f76913dd2db02c7b81483ae1c7d50aa Mon Sep 17 00:00:00 2001 From: Matthew Jasper Date: Sat, 4 Jul 2020 17:00:34 +0100 Subject: [PATCH 1170/2516] Document serialization in rustc --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/serialization.md | 164 +++++++++++++++++++ 2 files changed, 165 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/serialization.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 1fe7dcf11af5f..70c34f2a6def1 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/serialization.md b/src/doc/rustc-dev-guide/src/serialization.md new file mode 100644 index 0000000000000..252dcf8ac6e2d --- /dev/null +++ b/src/doc/rustc-dev-guide/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 40a8934753c97981d07198afb428fb139aaa846d Mon Sep 17 00:00:00 2001 From: Matthew Jasper Date: Sun, 16 Aug 2020 11:37:48 +0100 Subject: [PATCH 1171/2516] Address revuew comments --- src/doc/rustc-dev-guide/src/serialization.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/serialization.md b/src/doc/rustc-dev-guide/src/serialization.md index 252dcf8ac6e2d..292ffc5467b65 100644 --- a/src/doc/rustc-dev-guide/src/serialization.md +++ b/src/doc/rustc-dev-guide/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 2936e4e93bc294b99ed0a8d6804aae7a0b20a735 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 16 Aug 2020 14:51:37 -0500 Subject: [PATCH 1172/2516] Remove unneeded hashmarks (#826) Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/serialization.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/serialization.md b/src/doc/rustc-dev-guide/src/serialization.md index 292ffc5467b65..d28df6ec1e1e6 100644 --- a/src/doc/rustc-dev-guide/src/serialization.md +++ b/src/doc/rustc-dev-guide/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 02d89b704f8485fe9eb460caeb82f5ba478f5840 Mon Sep 17 00:00:00 2001 From: Lzu Tao Date: Mon, 17 Aug 2020 19:51:38 +0700 Subject: [PATCH 1173/2516] Link ref to edge concept in graph theory --- src/doc/rustc-dev-guide/src/queries/incremental-compilation.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md index 210d5b3918e7f..c8e7d4d7c7840 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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 c0ad2f923108299877cef71029b9b90c676c13fa Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Mon, 17 Aug 2020 16:10:29 +0200 Subject: [PATCH 1174/2516] Document how to use build task for x.py check (#828) --- .../rustc-dev-guide/src/building/suggested.md | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 08858507f94d6..0cc91b40343f0 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 18a74597ac16c65ee975b30a5cdee9ea0acc1672 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 19 Aug 2020 20:46:02 +0900 Subject: [PATCH 1175/2516] Remove duplicate MIR chapter entry (#830) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 5 ++--- src/doc/rustc-dev-guide/src/part-5-intro.md | 6 ++++-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 70c34f2a6def1..edf97c6dba0f2 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-5-intro.md b/src/doc/rustc-dev-guide/src/part-5-intro.md index 184d0ee3ae916..82663b5625e54 100644 --- a/src/doc/rustc-dev-guide/src/part-5-intro.md +++ b/src/doc/rustc-dev-guide/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 3c4555747238c31cb0bb91094be7106d54d259ab Mon Sep 17 00:00:00 2001 From: Gurwinder Singh Date: Fri, 21 Aug 2020 15:24:59 +0530 Subject: [PATCH 1176/2516] fix type in example (#832) Because the below explanation says that function type is `fn(u32) -> u32` --- src/doc/rustc-dev-guide/src/ty.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index d1e2750c11a18..49f6405fa791e 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 afc0efe2cba1e20df35544007fda35c1fb04d3c2 Mon Sep 17 00:00:00 2001 From: Guillaume Gomez Date: Sun, 23 Aug 2020 14:36:45 +0200 Subject: [PATCH 1177/2516] Add new section to have a local HTTP server easily (#833) --- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index d44e6679b91a5..f9c37ecd4a66e 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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 c81541279aba017a6f3607eb07b24ba2197cea63 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 22 Aug 2020 18:51:53 -0700 Subject: [PATCH 1178/2516] Clarify section on MIR construction --- src/doc/rustc-dev-guide/src/mir/construction.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 7fe9ee8840ede..2d5eef6d06d26 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 88f89f2c945c44da1c07f29286d93347fc6a9000 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 1179/2516] Apply review suggestion Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/mir/construction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 2d5eef6d06d26..50545f7763e14 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 916ffd71032cd25579450caaf9f72bcf7f60d8b9 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 26 Aug 2020 13:19:07 +0200 Subject: [PATCH 1180/2516] nits --- src/doc/rustc-dev-guide/src/mir/construction.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 50545f7763e14..010305556cf52 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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 fc3c322cec89954af5fadf575990248b559c2826 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 30 Aug 2020 14:35:45 -0500 Subject: [PATCH 1181/2516] fix links and names after compiler mv to compiler/ --- .../src/appendix/code-index.md | 46 +++++++++---------- .../rustc-dev-guide/src/appendix/glossary.md | 4 +- .../src/backend/backend-agnostic.md | 2 +- .../rustc-dev-guide/src/backend/codegen.md | 4 +- .../src/backend/lowering-mir.md | 12 ++--- .../src/borrow_check/region_inference.md | 2 +- .../rustc-dev-guide/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/doc/rustc-dev-guide/src/closure.md | 10 ++-- .../rustc-dev-guide/src/compiler-debugging.md | 32 ++++++------- src/doc/rustc-dev-guide/src/compiler-src.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics.md | 16 +++---- .../src/diagnostics/diagnostic-codes.md | 2 +- .../src/diagnostics/lintstore.md | 2 +- .../src/implementing_new_features.md | 2 +- src/doc/rustc-dev-guide/src/lowering.md | 2 +- .../rustc-dev-guide/src/macro-expansion.md | 14 +++--- src/doc/rustc-dev-guide/src/mir/index.md | 11 ++--- src/doc/rustc-dev-guide/src/miri.md | 8 ++-- .../rustc-dev-guide/src/name-resolution.md | 2 +- src/doc/rustc-dev-guide/src/overview.md | 30 ++++++------ .../src/panic-implementation.md | 6 +-- .../incremental-compilation-in-detail.md | 2 +- .../src/queries/incremental-compilation.md | 4 +- .../rustc-dev-guide/src/queries/profiling.md | 2 +- src/doc/rustc-dev-guide/src/query.md | 6 +-- .../src/stabilization_guide.md | 6 +-- .../src/test-implementation.md | 10 ++-- src/doc/rustc-dev-guide/src/the-parser.md | 12 ++--- src/doc/rustc-dev-guide/src/traits/chalk.md | 2 +- .../src/traits/goals-and-clauses.md | 4 +- src/doc/rustc-dev-guide/src/ty-fold.md | 2 +- src/doc/rustc-dev-guide/src/type-checking.md | 8 ++-- 35 files changed, 145 insertions(+), 146 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 8561efe4c0e92..9046cab138a78 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 748f4feb57111..007edce8d54fd 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/backend-agnostic.md b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md index 07914b847e7ba..e1eeb9a7fb08f 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/codegen.md b/src/doc/rustc-dev-guide/src/backend/codegen.md index 5db9b2b05c182..8e18ca2426c11 100644 --- a/src/doc/rustc-dev-guide/src/backend/codegen.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/lowering-mir.md b/src/doc/rustc-dev-guide/src/backend/lowering-mir.md index 2ab15e6f8c46a..8b9dbe7ce2a59 100644 --- a/src/doc/rustc-dev-guide/src/backend/lowering-mir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index 3b844b97c19eb..d8cfab00c28b7 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/bug-fix-procedure.md b/src/doc/rustc-dev-guide/src/bug-fix-procedure.md index b4159097c0cd8..69732b6275f79 100644 --- a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index a2eeb6029ebaf..d2384f9fca002 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 29d10edd096e9..f2f87e1d6c9c2 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index eea01e9cc6023..24d47edad7e93 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index 0f9b13965358c..3a7a10f5c87b1 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 0c40d63e48f4d..ead9b020bad93 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index df8bc2bd18061..324b9105ada11 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 5ad2fbb329bd0..a3293101fe617 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md index e0d144bfcf763..d5aae201ac1a3 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index 2942dac027ad0..8f0c21ab3d577 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 233d223dbbb46..2103c8803cfb6 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/lowering.md b/src/doc/rustc-dev-guide/src/lowering.md index e0dc99bab0ae8..a4d270b4dff06 100644 --- a/src/doc/rustc-dev-guide/src/lowering.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 1b06cab417337..7f704d05db69c 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index 85c5d755e9445..f771fa0ede533 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index 76996271d7272..af2a92802a2c2 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index cc6eed7f85f51..ebd44da1d761d 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 5bcf26911c1b2..baa1e0aa635cf 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index 1b4f827d4685b..308add57f9faa 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index 96255227faa49..bea9a886f9748 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/incremental-compilation.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md index c8e7d4d7c7840..5ff189f96ef76 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index 593d0b38547d5..ad31c9e5395de 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index be84fec54ceea..52786ad342546 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 73875bceb2049..2cdb0037bdcb7 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/test-implementation.md b/src/doc/rustc-dev-guide/src/test-implementation.md index a5ddd9135e76f..230e2fe364276 100644 --- a/src/doc/rustc-dev-guide/src/test-implementation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index da318c9ef3add..7c59ddfe741dc 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk.md b/src/doc/rustc-dev-guide/src/traits/chalk.md index 70af2a1f52d3b..659f6963772d0 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index f4ceb99a03d27..9aaab96faa7ad 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty-fold.md b/src/doc/rustc-dev-guide/src/ty-fold.md index 5b409e8ecab79..c390597f9a68f 100644 --- a/src/doc/rustc-dev-guide/src/ty-fold.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-checking.md b/src/doc/rustc-dev-guide/src/type-checking.md index d4f4bf1107e51..797cd9487a887 100644 --- a/src/doc/rustc-dev-guide/src/type-checking.md +++ b/src/doc/rustc-dev-guide/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 0307e1fd3fc47b74828ad18705c48408bca05965 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 30 Aug 2020 14:51:48 -0500 Subject: [PATCH 1182/2516] fix line lengths --- src/doc/rustc-dev-guide/src/panic-implementation.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index 308add57f9faa..7c10ae215b8d3 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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 e62c329118ce1c928782e25e3f9c7f620d772020 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 30 Aug 2020 14:58:29 -0500 Subject: [PATCH 1183/2516] fix typos --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 9046cab138a78..345a99b4f1091 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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 fbef57a6f9b3685cb73414edb44609d06803f5b0 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 30 Aug 2020 21:15:08 -0500 Subject: [PATCH 1184/2516] Typo Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 345a99b4f1091..68d12be37bf79 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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 e467729bc35ca20584f4ad0e4b2665c57f058928 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 30 Aug 2020 22:20:09 -0400 Subject: [PATCH 1185/2516] 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. --- .../rustc-dev-guide/src/building/how-to-build-and-run.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index f2f87e1d6c9c2..364a307d33c13 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 08f6fbe6aa83a3829ba587091b4277786815bbb0 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 30 Aug 2020 22:09:57 -0400 Subject: [PATCH 1186/2516] Use fewer stages in bootstrapping docs After https://github.com/rust-lang/rust/pull/73964, they're redundant. --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index d2384f9fca002..ed0d9693cfe5f 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 9274f5d595f949b371487fec80229df6a572c2c9 Mon Sep 17 00:00:00 2001 From: Rich Kadel Date: Tue, 1 Sep 2020 14:57:35 -0700 Subject: [PATCH 1187/2516] Adds documentation to cover spanview output Documents the feature introduced in #76074. --- .../rustc-dev-guide/src/compiler-debugging.md | 18 ++++++++++++++++++ src/doc/rustc-dev-guide/src/mir/debugging.md | 14 +++++++++++--- 2 files changed, 29 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index ead9b020bad93..fce579253f4ba 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/debugging.md b/src/doc/rustc-dev-guide/src/mir/debugging.md index 93a79076c3074..edb68ca720267 100644 --- a/src/doc/rustc-dev-guide/src/mir/debugging.md +++ b/src/doc/rustc-dev-guide/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 d0ef3a97fb5f7a375b2cdead44b4895fbbab21a3 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 3 Sep 2020 09:54:06 -0300 Subject: [PATCH 1188/2516] Fix dep-graph-caller-callee test location --- src/doc/rustc-dev-guide/src/incrcomp-debugging.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/incrcomp-debugging.md b/src/doc/rustc-dev-guide/src/incrcomp-debugging.md index ecb29d544e4b1..ba312c959e4c8 100644 --- a/src/doc/rustc-dev-guide/src/incrcomp-debugging.md +++ b/src/doc/rustc-dev-guide/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 6500603ef19593b0f1351d099ee9e561e38c2cb7 Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Thu, 3 Sep 2020 15:56:29 -0700 Subject: [PATCH 1189/2516] update docs to refer to the move --- src/doc/rustc-dev-guide/src/compiler-src.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 324b9105ada11..843000a0731b1 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 e381ca3f2c0c812d99a38763d7f3afe25cc07a95 Mon Sep 17 00:00:00 2001 From: Ivan Tham Date: Sun, 6 Sep 2020 22:14:19 +0800 Subject: [PATCH 1190/2516] Rename src/rustc to compiler/rustc --- src/doc/rustc-dev-guide/src/getting-started.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 055551c60ab02..9c67f3dc4bce3 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 26d3f1fb5cb906e99843f6c51143e2326cc5640f Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 6 Sep 2020 15:00:21 -0400 Subject: [PATCH 1191/2516] 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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 364a307d33c13..f526223226792 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 1bb94b708e325d665f6ac5517e4f5b504e1b1f73 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 7 Sep 2020 11:16:03 +0200 Subject: [PATCH 1192/2516] Update src/building/how-to-build-and-run.md --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index f526223226792..1e67024988bde 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 444512da34f5162f1d55085d70b2d5ed7a753f79 Mon Sep 17 00:00:00 2001 From: Aman Arora Date: Thu, 3 Sep 2020 22:46:56 -0400 Subject: [PATCH 1193/2516] Document CGU partioning in case of generic and inline functions --- .../rustc-dev-guide/src/backend/monomorph.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index 47b41d4f6c9f9..e678b4f76c0c0 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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 f183ea18f1d0d31fa46efae215272e7f0ef9c819 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 7 Sep 2020 11:25:11 -0400 Subject: [PATCH 1194/2516] 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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index ed0d9693cfe5f..dd24699fe0956 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 1e67024988bde..00127d56014d2 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 a41c911218fb3ccad1a88f77e5603d9f36cbdb77 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 30 Aug 2020 23:01:52 -0400 Subject: [PATCH 1195/2516] 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/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md index d5aae201ac1a3..092c8a2f8d001 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-codes.md +++ b/src/doc/rustc-dev-guide/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 7b9ad6b4b7306af757908833c2f5e54102a3a2ff Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 03:19:01 -0400 Subject: [PATCH 1196/2516] Document speculative crate loading (#859) --- src/doc/rustc-dev-guide/src/name-resolution.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index ebd44da1d761d..3785e3aa78256 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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 09a931a4aae4cb17a1213d8dc0c7dcad636cd3d6 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 8 Sep 2020 23:24:18 -0400 Subject: [PATCH 1197/2516] Fix typo --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index dd24699fe0956..697ca80d13ac9 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 0bb78aaad6d8807e7983ba2efb4953d89a5c85c0 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 09:18:59 -0400 Subject: [PATCH 1198/2516] Add information about default stages for x.py --- .../rustc-dev-guide/src/building/bootstrapping.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 697ca80d13ac9..7116d908aa702 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 4373430365e446a0d03a2911ffeddccdee9f155f Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 12:22:56 -0400 Subject: [PATCH 1199/2516] Fix broken hyperlink (#862) * Fix broken hyperlink * Link to previous pages instead of skipping ahead * Fix line lengths --- src/doc/rustc-dev-guide/src/building/suggested.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 0cc91b40343f0..424452b6273fe 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 3bbe9b8fa1036464dfecf83c64baae4d23ccfed9 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 12:24:01 -0400 Subject: [PATCH 1200/2516] 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/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index f4b0a92a4e042..63d5aca8e9060 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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 f7bf37a53fedf96eb9347933f3668ecd5a1c094c Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 3 Sep 2020 17:45:19 -0300 Subject: [PATCH 1201/2516] Add ./ to run x.py --- src/doc/rustc-dev-guide/src/queries/profiling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index ad31c9e5395de..fc8846fc5c5fd 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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 176fd1015aa21c974c0999063d418da2dbda2816 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 3 Sep 2020 18:14:12 -0300 Subject: [PATCH 1202/2516] Fix typo, hellow -> hello --- src/doc/rustc-dev-guide/src/queries/profiling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index fc8846fc5c5fd..a89e05c74cccb 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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 5ddb5ca1867650d4606984d923b862f122ea8019 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 3 Sep 2020 18:16:53 -0300 Subject: [PATCH 1203/2516] Update def_id.rs location --- src/doc/rustc-dev-guide/src/queries/profiling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index a89e05c74cccb..ec04ad2c3ad99 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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 447654ef9e02be29b5ea18252854b07f553282c5 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 9 Sep 2020 16:24:41 +0000 Subject: [PATCH 1204/2516] Update src/queries/profiling.md Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/queries/profiling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index ec04ad2c3ad99..7e0b686869a09 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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 cbdf90fd573906b92ece5ef4f75b2293576e036e Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 8 Sep 2020 20:14:05 -0400 Subject: [PATCH 1205/2516] Document how to promote a target from cross-compiled to hosted --- src/doc/rustc-dev-guide/src/building/new-target.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index 24d47edad7e93..022f8f1fb0841 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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 94e1af9bb365c972f3a49308804e8a49d018f4be Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 9 Sep 2020 17:00:32 +0200 Subject: [PATCH 1206/2516] Update src/building/new-target.md --- src/doc/rustc-dev-guide/src/building/new-target.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index 022f8f1fb0841..91b337052f194 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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 fc36c660b9084edf53696fab2623d127e65e6be1 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 14:36:46 -0400 Subject: [PATCH 1207/2516] Fix nit --- src/doc/rustc-dev-guide/src/building/new-target.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index 91b337052f194..3bb77f7fc0a46 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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 2aa10fa52c15ff91476f7400dd92bd16cfd0991c Mon Sep 17 00:00:00 2001 From: Rich Kadel Date: Wed, 9 Sep 2020 15:13:18 -0700 Subject: [PATCH 1208/2516] broken intra-page link from spanview to graphviz Just noticed the link was not correct. Fixed here. --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index fce579253f4ba..9c69b15116824 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 3e02cacb225dd89878e5b324ffcfcd647d8fd1bc Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 8 Sep 2020 13:32:09 -0700 Subject: [PATCH 1209/2516] 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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 00127d56014d2..0c96545ca82d8 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 6331ffdbcd208f6165fd6a32087488be044694be Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 20:54:14 -0400 Subject: [PATCH 1210/2516] Use imprecise times, because the time to build depends on your computer Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 0c96545ca82d8..af6123e16a538 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 8ad13b0c88b2b030d2baab60908f6c2f1676f849 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 9 Sep 2020 17:16:17 -0700 Subject: [PATCH 1211/2516] Update "Helpful Links" section --- src/doc/rustc-dev-guide/src/contributing.md | 27 ++++++++++----------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index e835eef8422ae..c79dd3e3ff2f8 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 390716c873b29322570e24355354f2feb734462a Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 9 Sep 2020 18:38:42 -0700 Subject: [PATCH 1212/2516] Add more info about Rustdoc --- src/doc/rustc-dev-guide/src/contributing.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index c79dd3e3ff2f8..98b1a2d7ffbba 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 a5649c031899f3b4ba0fd09969deb364fac684eb 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 1213/2516] Add back comma Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 98b1a2d7ffbba..4ec87f78c232f 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 81b8c1b555de74bdaf82f5482513aa4fe61d3534 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 9 Sep 2020 19:29:47 -0700 Subject: [PATCH 1214/2516] Add back information about Googling Also cleaned up some other things. --- src/doc/rustc-dev-guide/src/contributing.md | 36 ++++++++++++--------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 4ec87f78c232f..80b3ea5a467fa 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 917a1a0658f4c40acf2415bf83dcb02fd28278f8 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Thu, 10 Sep 2020 18:29:08 -0400 Subject: [PATCH 1215/2516] Fix incorrect docs about stages `build library/core` builds the compiler, not just the standard library. --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index af6123e16a538..07c8ed0697363 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 69299dc0699a462e375e4e4a1bfcaca2b828e038 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Thu, 10 Sep 2020 23:50:12 -0400 Subject: [PATCH 1216/2516] Fix other library commands --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 07c8ed0697363..177fa20d208a1 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 531b8d5d5026ea9c1d2225d37c1bd044669dcb02 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Thu, 10 Sep 2020 17:05:38 +0200 Subject: [PATCH 1217/2516] Clean up 'Contributing to Rust - Pull Requests' --- src/doc/rustc-dev-guide/src/contributing.md | 90 ++++++++++++--------- 1 file changed, 54 insertions(+), 36 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 80b3ea5a467fa..b7f0b7f5c3812 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 f9e705071e46b609cdc8ab0215642282f16aadfc Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Thu, 10 Sep 2020 17:59:53 +0200 Subject: [PATCH 1218/2516] Apply suggestions from code review Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/contributing.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index b7f0b7f5c3812..350b991a43a6a 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 7ccdf4c015af4bb49c1ad6586225c30e4cc90ba8 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 11 Sep 2020 13:02:54 +0200 Subject: [PATCH 1219/2516] Fix typo Co-authored-by: Tshepang Lekhonkhobe --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 350b991a43a6a..f158d16354b90 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 453611df6fdce089937654050281d8736776ff7b Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Fri, 11 Sep 2020 16:49:05 -0700 Subject: [PATCH 1220/2516] Improve link and description of entry points in parser section (#876) This seemed to be out of date! --- src/doc/rustc-dev-guide/src/the-parser.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index 7c59ddfe741dc..d3e48a17e72f9 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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 87b9d337b96ee4c90045ba496027d4675a6d6e31 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 11 Sep 2020 18:41:51 +0200 Subject: [PATCH 1221/2516] Add a chapter on useful `@rustbot` commands --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/contributing.md | 17 ++++-- src/doc/rustc-dev-guide/src/rustbot.md | 62 +++++++++++++++++++++ 3 files changed, 76 insertions(+), 4 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/rustbot.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index edf97c6dba0f2..d1560c960a765 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index f158d16354b90..af3bd7b81174c 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustbot.md b/src/doc/rustc-dev-guide/src/rustbot.md new file mode 100644 index 0000000000000..1c75b6ebace6b --- /dev/null +++ b/src/doc/rustc-dev-guide/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 a28c6a4c8635a04d0aad37ae4c4427a12add3605 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 11 Sep 2020 21:59:39 +0200 Subject: [PATCH 1222/2516] Update src/contributing.md --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index af3bd7b81174c..98dbb4638e9f7 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 d6f629822d454c99e4544bd2487a77395433f9be Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 11 Sep 2020 21:59:48 +0200 Subject: [PATCH 1223/2516] Update src/contributing.md Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 98dbb4638e9f7..2289ede194690 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 9b1cee69118544a31d3c5cb2782d00f4651484ea Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 11 Sep 2020 22:02:13 +0200 Subject: [PATCH 1224/2516] Update src/rustbot.md --- src/doc/rustc-dev-guide/src/rustbot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustbot.md b/src/doc/rustc-dev-guide/src/rustbot.md index 1c75b6ebace6b..880c35a82418c 100644 --- a/src/doc/rustc-dev-guide/src/rustbot.md +++ b/src/doc/rustc-dev-guide/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 2961c91f123d505ba5a5059dfb2d0f8f3121d12b Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 11 Sep 2020 22:04:04 +0200 Subject: [PATCH 1225/2516] Update src/rustbot.md --- src/doc/rustc-dev-guide/src/rustbot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustbot.md b/src/doc/rustc-dev-guide/src/rustbot.md index 880c35a82418c..d7164d0e08d72 100644 --- a/src/doc/rustc-dev-guide/src/rustbot.md +++ b/src/doc/rustc-dev-guide/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 293aad50817252c6cf00c84b10339504209d9abb Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 12 Sep 2020 15:28:15 +0200 Subject: [PATCH 1226/2516] Apply suggestions from code review Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- src/doc/rustc-dev-guide/src/rustbot.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 2289ede194690..08ece467ccf26 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustbot.md b/src/doc/rustc-dev-guide/src/rustbot.md index d7164d0e08d72..d0bbee301d373 100644 --- a/src/doc/rustc-dev-guide/src/rustbot.md +++ b/src/doc/rustc-dev-guide/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 5baa430ffecafb43f175f4f677173a872c0274fc Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 12 Sep 2020 17:35:53 +0200 Subject: [PATCH 1227/2516] Hide `@rustdoc` implementation details --- src/doc/rustc-dev-guide/src/rustbot.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustbot.md b/src/doc/rustc-dev-guide/src/rustbot.md index d0bbee301d373..275e07a70cf08 100644 --- a/src/doc/rustc-dev-guide/src/rustbot.md +++ b/src/doc/rustc-dev-guide/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 90f6ed4b825911371e6dc412e93b371b73af7723 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 12 Sep 2020 17:56:53 +0200 Subject: [PATCH 1228/2516] Fix typo --- src/doc/rustc-dev-guide/src/rustbot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustbot.md b/src/doc/rustc-dev-guide/src/rustbot.md index 275e07a70cf08..53211f2975bd3 100644 --- a/src/doc/rustc-dev-guide/src/rustbot.md +++ b/src/doc/rustc-dev-guide/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 cae32c9e598a46f107a69d99327b68624e5f792b Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 8 Sep 2020 20:20:08 -0400 Subject: [PATCH 1229/2516] Document edition flag for UI tests --- src/doc/rustc-dev-guide/src/tests/adding.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index c74f6cec4fe86..57ee49338b70c 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 27d5948e409caaa95e95b7e381f7777a3432d9c6 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 08:50:04 -0400 Subject: [PATCH 1230/2516] Note that the default is 2015 --- src/doc/rustc-dev-guide/src/tests/adding.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 57ee49338b70c..4576e377e024d 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 fde149364d83f4c744c458bde9efd27ec80f5076 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 20:38:53 -0400 Subject: [PATCH 1231/2516] Address nits --- src/doc/rustc-dev-guide/src/tests/adding.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 4576e377e024d..c88d5e81df69d 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 435040d12530d9610e9885e4aea11660b80448e6 Mon Sep 17 00:00:00 2001 From: Monadic Cat Date: Sat, 12 Sep 2020 17:06:58 -0500 Subject: [PATCH 1232/2516] correct attribute used here --- src/doc/rustc-dev-guide/src/stability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 9255f4b57bc38..1cbbcb8493069 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 f9d3b7f4db5198472accef019a859a581fdbbbc7 Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Sat, 12 Sep 2020 19:20:37 -0700 Subject: [PATCH 1233/2516] Initial draft of MIR dataflow framework docs --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/mir/dataflow.md | 165 ++++++++++++++++++++ 2 files changed, 166 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/mir/dataflow.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index d1560c960a765..25ea76e78830e 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md new file mode 100644 index 0000000000000..abe04e376c039 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 f75d4b1eb99c749e0670cdda1ff2bca3e849b3e6 Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Sun, 13 Sep 2020 12:22:57 -0700 Subject: [PATCH 1234/2516] Add missing link to `Engine` --- src/doc/rustc-dev-guide/src/mir/dataflow.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index abe04e376c039..e83c4ebb3bf6b 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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 c6e556591e6406b3fadb5db4feb2be09b4bb48b7 Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Sun, 13 Sep 2020 12:24:46 -0700 Subject: [PATCH 1235/2516] Line edits --- src/doc/rustc-dev-guide/src/mir/dataflow.md | 53 +++++++++++---------- 1 file changed, 29 insertions(+), 24 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index e83c4ebb3bf6b..9f93921b4b067 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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 153e35ff276436b16e49c0e47d78d03679d5da47 Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Sun, 13 Sep 2020 12:30:29 -0700 Subject: [PATCH 1236/2516] Update `Visitor` and `Cursor` examples --- src/doc/rustc-dev-guide/src/mir/dataflow.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index 9f93921b4b067..5b10afec1f373 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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 03eaf2a306a5e06b10ffd00a16336b85dafe9322 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 11 Sep 2020 00:29:15 +0200 Subject: [PATCH 1237/2516] Add a chapter on all the identifiers used through `rustc` --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/identifiers.md | 63 ++++++++++++++++++++++ 2 files changed, 64 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/identifiers.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 25ea76e78830e..8915541cdf568 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/identifiers.md b/src/doc/rustc-dev-guide/src/identifiers.md new file mode 100644 index 0000000000000..852bfe8a73da5 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 b89337828ee495152a3cadf630c9fdbd32bd5be8 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 11 Sep 2020 01:10:07 +0200 Subject: [PATCH 1238/2516] Apply suggestions from code review Co-authored-by: Tshepang Lekhonkhobe --- src/doc/rustc-dev-guide/src/identifiers.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/identifiers.md b/src/doc/rustc-dev-guide/src/identifiers.md index 852bfe8a73da5..a672c027459ce 100644 --- a/src/doc/rustc-dev-guide/src/identifiers.md +++ b/src/doc/rustc-dev-guide/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 9688d2dc295a1354ae890fcc738b64f1e265b2e6 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 11 Sep 2020 17:14:48 +0200 Subject: [PATCH 1239/2516] Make the HIR chapter point to the new chapter on IDs --- src/doc/rustc-dev-guide/src/hir.md | 46 +++++++----------------------- 1 file changed, 10 insertions(+), 36 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 8b6637ebedcfe..47262c485383d 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 55aa7e3dd75aac1cf79addca63e4cf0f7b523ceb Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 12 Sep 2020 20:41:12 +0200 Subject: [PATCH 1240/2516] Fix typo Co-authored-by: Who? Me?! --- src/doc/rustc-dev-guide/src/identifiers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/identifiers.md b/src/doc/rustc-dev-guide/src/identifiers.md index a672c027459ce..f485132c64027 100644 --- a/src/doc/rustc-dev-guide/src/identifiers.md +++ b/src/doc/rustc-dev-guide/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 b2ef7902647dd1064d0c6ba006f784adc83690d6 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 1241/2516] Bump mdbook version 0.4.1 -> 0.4.3 --- src/doc/rustc-dev-guide/.travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 304abbf8f7129..2da87a1258ff2 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 1fce3538fe7573652c4b484d9a98fd1cd4b3f767 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 1242/2516] Use latest patch release of mdBook and linkcheck --- src/doc/rustc-dev-guide/.travis.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 2da87a1258ff2..fba5ab87e10c2 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 699c4ea15d3abbea577b4d3e16e57f4d64ecf8c9 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 14 Sep 2020 16:37:37 -0300 Subject: [PATCH 1243/2516] Add Salsa In More Depth lecture --- src/doc/rustc-dev-guide/src/salsa.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index 68e92b29fd3d1..8e2ba6dcb51f1 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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 6651dfc4e49680e2bfe7cb817666534d26fa1eb3 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 14 Sep 2020 16:41:25 -0300 Subject: [PATCH 1244/2516] Complete text about salsa base inputs --- src/doc/rustc-dev-guide/src/salsa.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index 8e2ba6dcb51f1..f884ecdda2c7f 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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 bcf72c504918c28a2b4fa2d88d4ced684b1a028e Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 14 Sep 2020 16:43:34 -0300 Subject: [PATCH 1245/2516] Remove EN1 --- src/doc/rustc-dev-guide/src/salsa.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index f884ecdda2c7f..567f1b153a866 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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 32ea891485292cc40e5b3b27c9217304e6bc931a Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Tue, 15 Sep 2020 19:20:11 -0700 Subject: [PATCH 1246/2516] Describe how to generate graphviz diagrams for dataflow --- .../src/img/dataflow-graphviz-example.png | Bin 0 -> 81892 bytes src/doc/rustc-dev-guide/src/mir/dataflow.md | 16 ++++++++++++++++ src/doc/rustc-dev-guide/src/mir/debugging.md | 4 ++++ 3 files changed, 20 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/img/dataflow-graphviz-example.png diff --git a/src/doc/rustc-dev-guide/src/img/dataflow-graphviz-example.png b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index 5b10afec1f373..be8d4fb988602 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/debugging.md b/src/doc/rustc-dev-guide/src/mir/debugging.md index edb68ca720267..3a47a575d59ad 100644 --- a/src/doc/rustc-dev-guide/src/mir/debugging.md +++ b/src/doc/rustc-dev-guide/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 4b013d3193566771d2d29e42ab8208c231d1dfea Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Tue, 15 Sep 2020 21:18:37 -0700 Subject: [PATCH 1247/2516] Add link for `AnalysisDomain::NAME` --- src/doc/rustc-dev-guide/src/mir/dataflow.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index be8d4fb988602..bc65ecfa2741b 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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 72d3b5ab2868a749cc6d28d268ac4e2ac04e4149 Mon Sep 17 00:00:00 2001 From: Macdonald Umoren Date: Wed, 16 Sep 2020 20:50:33 -0400 Subject: [PATCH 1248/2516] debug-logging=true instead of debug-assertions=yes --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 9c69b15116824..e4b04aa969205 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 3829c92694025e100be9928d679b2b879305a45a Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 14 Sep 2020 16:38:26 -0700 Subject: [PATCH 1249/2516] 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/doc/rustc-dev-guide/src/appendix/background.md b/src/doc/rustc-dev-guide/src/appendix/background.md index e7b9f3afc1493..07515aeab081c 100644 --- a/src/doc/rustc-dev-guide/src/appendix/background.md +++ b/src/doc/rustc-dev-guide/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 d706ba09dbeec956cdbc19d5100038e6c227a3b2 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 14 Sep 2020 16:41:25 -0700 Subject: [PATCH 1250/2516] More improvements --- src/doc/rustc-dev-guide/src/appendix/background.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/background.md b/src/doc/rustc-dev-guide/src/appendix/background.md index 07515aeab081c..ae6136dd553ea 100644 --- a/src/doc/rustc-dev-guide/src/appendix/background.md +++ b/src/doc/rustc-dev-guide/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 c72daace49a02ead50e0f648cf2d463ad267373d Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 14 Sep 2020 18:56:22 -0700 Subject: [PATCH 1251/2516] Mention that places are sometimes called "lvalues" --- src/doc/rustc-dev-guide/src/mir/index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index f771fa0ede533..fd55046ec8d53 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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 9d5753910d3c5ffa9dbf448f1779cea17545306e Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 14 Sep 2020 19:13:44 -0700 Subject: [PATCH 1252/2516] Revert "Mention that places are sometimes called "lvalues"" This reverts commit bf5e1c451de505fa453672c1168b09db07a145cb. --- src/doc/rustc-dev-guide/src/mir/index.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index fd55046ec8d53..f771fa0ede533 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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 3fd9f3bd08f5d7d7dc841f9c44b5e5685885b1a8 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 14 Sep 2020 20:18:28 -0700 Subject: [PATCH 1253/2516] Fix typo in table of contents --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 8915541cdf568..5bd0387806368 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 0d195f113bff1891bb27b961ff8bdfb4b0d2f44c Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sat, 19 Sep 2020 19:40:17 -0400 Subject: [PATCH 1254/2516] 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/doc/rustc-dev-guide/src/tests/adding.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index c88d5e81df69d..acdc2fd251cc0 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 08162cbd1e4c72869a23141827e953055f8a1475 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 1255/2516] `ConstEvalResult` is now `EvalToConstValueResult` (#885) Also fixed typo. --- src/doc/rustc-dev-guide/src/const-eval.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/const-eval.md b/src/doc/rustc-dev-guide/src/const-eval.md index 2a5c5d2f97505..d21d0ea58172a 100644 --- a/src/doc/rustc-dev-guide/src/const-eval.md +++ b/src/doc/rustc-dev-guide/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 30ca044a7199d13a357a89ddf45c3f23729d5e4c Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 23 Sep 2020 11:46:43 -0400 Subject: [PATCH 1256/2516] 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/doc/rustc-dev-guide/src/tests/running.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 1043f87a19cfa..5e18b8a95992c 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 9373c8d588f78b43903423b63a2223fdc38f3d88 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 1257/2516] 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/doc/rustc-dev-guide/src/mir/optimizations.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index 3c143d5557671..65323ed52e488 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 370b79975ced84fe1c17eee2632df9a2ac8a9651 Mon Sep 17 00:00:00 2001 From: Jakob Degen Date: Thu, 24 Sep 2020 10:44:20 -0400 Subject: [PATCH 1258/2516] 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/doc/rustc-dev-guide/src/conventions.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index b9001ee0bbea0..582de036493ba 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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 268028e25928e9fb31271f360b66dc6aae61ee42 Mon Sep 17 00:00:00 2001 From: Youngsuk_Kim Date: Fri, 25 Sep 2020 17:23:37 -0400 Subject: [PATCH 1259/2516] minor punctuation/grammar error fix --- src/doc/rustc-dev-guide/src/closure.md | 6 +++--- src/doc/rustc-dev-guide/src/compiler-src.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index 3a7a10f5c87b1..665f7734eef58 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 843000a0731b1..5183a7c85b8bd 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 3ee6367d1e116531821ee8ff275726bac912013a Mon Sep 17 00:00:00 2001 From: Youngsuk_Kim Date: Fri, 25 Sep 2020 17:39:17 -0400 Subject: [PATCH 1260/2516] update description of 'ByRef' borrows of closures --- src/doc/rustc-dev-guide/src/closure.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index 665f7734eef58..4e6e69d1d2e8a 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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 34cfcbcf2628272f830e24107f8e6950d039e298 Mon Sep 17 00:00:00 2001 From: Youngsuk_Kim Date: Fri, 25 Sep 2020 22:42:13 -0400 Subject: [PATCH 1261/2516] add link to 'BorrowKind' in closure.md --- src/doc/rustc-dev-guide/src/closure.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index 4e6e69d1d2e8a..f357eed9cccfb 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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 14fc590808f7c6530fbd6762fd76fa04d00b249b Mon Sep 17 00:00:00 2001 From: Youngsuk_Kim Date: Fri, 25 Sep 2020 22:50:50 -0400 Subject: [PATCH 1262/2516] update link to 'BorrowKind' to be implicit in markdown --- src/doc/rustc-dev-guide/src/closure.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index f357eed9cccfb..3b535040e8e43 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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 aace4f0c24732a5e26cc0abba2e7c83fe9b24172 Mon Sep 17 00:00:00 2001 From: "Shahar Or (mightyiam)" Date: Sat, 26 Sep 2020 15:17:19 +0700 Subject: [PATCH 1263/2516] correct output path in Writing Documentation --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 08ece467ccf26..0415f8e08fd72 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 df11ed503fac64bc93093769034455a3bfd0c687 Mon Sep 17 00:00:00 2001 From: follower Date: Sun, 27 Sep 2020 04:08:41 +1300 Subject: [PATCH 1264/2516] 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/doc/rustc-dev-guide/src/getting-started.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 9c67f3dc4bce3..75838060cd637 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 8a8ae8ca9bb5fe40c50da2104b9c73cd91a49b90 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sat, 26 Sep 2020 16:05:06 -0400 Subject: [PATCH 1265/2516] Add docs for x.py setup --- .../rustc-dev-guide/src/getting-started.md | 35 +++++++++++-------- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 75838060cd637..66b5389b733b6 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 edceee064f4f625cf06b004f6d9900adeea33569 Mon Sep 17 00:00:00 2001 From: follower Date: Sun, 27 Sep 2020 04:22:47 +1300 Subject: [PATCH 1266/2516] Add links to documentation sources. Linking directly to the relevant/example document source locations makes it easier for potential contributors to find them. --- src/doc/rustc-dev-guide/src/contributing.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 0415f8e08fd72..ba446b2745fa9 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 0e2c9cccb95dfbd7a723beffbe5a09d118d99e48 Mon Sep 17 00:00:00 2001 From: follower Date: Sun, 27 Sep 2020 04:40:15 +1300 Subject: [PATCH 1267/2516] Fix line length error. Reduced line length to <100 (as indicated by PR build error). (Also removed extra space character before link.) --- src/doc/rustc-dev-guide/src/contributing.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index ba446b2745fa9..b797a6b0abe44 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 2e9a2f3c754da557728f9768dbb8f9c8c85a36ef Mon Sep 17 00:00:00 2001 From: follower Date: Sun, 27 Sep 2020 22:16:59 +1300 Subject: [PATCH 1268/2516] Use implicit reference links for shorter lines (As suggested by jyn514.) --- src/doc/rustc-dev-guide/src/contributing.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index b797a6b0abe44..5dd80c93349e6 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 c714aed30a8efc567a315df373f64b901778f47a Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 29 Sep 2020 15:18:00 +0000 Subject: [PATCH 1269/2516] --verbose is useful when not compiling and when compiling (#901) --- src/doc/rustc-dev-guide/src/cli.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/cli.md b/src/doc/rustc-dev-guide/src/cli.md index f47c89e1f9b79..408ae20700430 100644 --- a/src/doc/rustc-dev-guide/src/cli.md +++ b/src/doc/rustc-dev-guide/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 61b48efae13c43e5eeb95d4d0a2fab0dd70e7bb7 Mon Sep 17 00:00:00 2001 From: Jakob Degen Date: Thu, 24 Sep 2020 10:10:52 -0400 Subject: [PATCH 1270/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/git.md | 203 +++++++++++++++++++++++++ 2 files changed, 204 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/git.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 5bd0387806368..eaefb2ed4c043 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md new file mode 100644 index 0000000000000..07e30c2de2845 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 40b87ba3a1b572d0102f1a5f6aa64442fde2be5e Mon Sep 17 00:00:00 2001 From: Jakob Degen Date: Thu, 24 Sep 2020 16:48:55 -0400 Subject: [PATCH 1271/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/git.md | 86 +++++++++++--------------- 2 files changed, 36 insertions(+), 52 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index eaefb2ed4c043..0e52a2e08ff8d 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 07e30c2de2845..b6b8525875b2b 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 04a36c83e7dd14baf5650639c7401aea63ce06c6 Mon Sep 17 00:00:00 2001 From: Jakob Degen Date: Fri, 25 Sep 2020 15:30:29 -0400 Subject: [PATCH 1272/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/git.md | 97 ++++++++++++++------------ 2 files changed, 52 insertions(+), 47 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 0e52a2e08ff8d..f3ebe4da80fbc 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index b6b8525875b2b..9f025ff61e67e 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 2bb145daa4e067a7bb19b87e7eae8f48f1938aed Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 30 Sep 2020 13:19:46 -0400 Subject: [PATCH 1273/2516] Fix typo --- src/doc/rustc-dev-guide/src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 9f025ff61e67e..5f88235c2f65c 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 059dc4360166fdfb6cb64bf170d45f89f763d178 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Thu, 24 Sep 2020 09:29:46 -0400 Subject: [PATCH 1274/2516] 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 --- src/doc/rustc-dev-guide/README.md | 11 +++++++++++ .../rustc-dev-guide/ci/check_line_lengths.sh | 17 ++++++++--------- 2 files changed, 19 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 5dbd5d27f35db..fd83cea2d5bf7 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/check_line_lengths.sh b/src/doc/rustc-dev-guide/ci/check_line_lengths.sh index 32bf739e4dc24..8ecb8a309b64c 100755 --- a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh +++ b/src/doc/rustc-dev-guide/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 3187a75639e94c2eb84d7bf95c4dfc1b5291f20c Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 29 Sep 2020 11:43:11 -0400 Subject: [PATCH 1275/2516] Add windows instructions --- src/doc/rustc-dev-guide/README.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index fd83cea2d5bf7..99e781490a735 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 2e299034d0b2fbfc3da14428ad66f8069a8c37d6 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 30 Sep 2020 21:01:48 -0400 Subject: [PATCH 1276/2516] Fix incorrect windows link Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 99e781490a735..aab497af30c7e 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 c1c6dac0b51f167e63465f46e00d23af8cda5ab3 Mon Sep 17 00:00:00 2001 From: Roman Date: Fri, 2 Oct 2020 09:42:41 +0200 Subject: [PATCH 1277/2516] add the last missing code highlight to t-compiler in the docs --- src/doc/rustc-dev-guide/src/getting-started.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 66b5389b733b6..1f338a6617aa8 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 2571db38e46e97abfdf8b8ed6fd289875b7b4b1a Mon Sep 17 00:00:00 2001 From: Camelid Date: Fri, 2 Oct 2020 11:55:43 -0700 Subject: [PATCH 1278/2516] Fix instructions for squashing `git merge-base master` does not work, you need `git merge-base master HEAD` instead. --- src/doc/rustc-dev-guide/src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 5f88235c2f65c..633e7d5725eee 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 33b684b11553482cebce35285e2f58880f084b70 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 4 Oct 2020 03:30:36 +0900 Subject: [PATCH 1279/2516] Fix the report link --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index ff09a26b0d4e1..1453f85da9996 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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 0eaa94c09044a957df31b0c0988d6fc8f7288857 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 1280/2516] 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/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index 1453f85da9996..b5defaefd25e8 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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 86b81f478bb3088519c7f55a98e8a863e60c7cf3 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 3 Oct 2020 20:30:30 +0200 Subject: [PATCH 1281/2516] Add a paragraph about reviewers and review latency in Getting Started chapter --- src/doc/rustc-dev-guide/src/getting-started.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 1f338a6617aa8..1f5a691eeffb8 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 d380f2ea0910d59bbcf9a9e2b7f78860b74d6360 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sat, 3 Oct 2020 20:48:15 +0200 Subject: [PATCH 1282/2516] Update src/getting-started.md Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 1f5a691eeffb8..26558e836f719 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 9180ec2139c7fe236274b4251fd5604945176521 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sat, 3 Oct 2020 20:48:24 +0200 Subject: [PATCH 1283/2516] Update src/getting-started.md Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 26558e836f719..d9070f706f819 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 e7c8adc14d97310ef238774b95fec13e5f7527ca Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 3 Oct 2020 22:49:38 +0200 Subject: [PATCH 1284/2516] Fix time periods for Triage WG procedure --- src/doc/rustc-dev-guide/src/getting-started.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index d9070f706f819..5837e9423910b 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 3bbc7f387ba2ed4c97efa97236bfe7148337a017 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 25 Sep 2020 17:03:54 -0300 Subject: [PATCH 1285/2516] hir_map -> hir() --- src/doc/rustc-dev-guide/src/hir.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 47262c485383d..5757d1e778669 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 eb1c1fa27e51d921f695b7cd919f1cd350668ac9 Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Sun, 13 Sep 2020 21:11:06 +0200 Subject: [PATCH 1286/2516] Document new way to not build LLVM Implemented in https://github.com/rust-lang/rust/pull/76349 --- .../rustc-dev-guide/src/building/suggested.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 424452b6273fe..cc8d92a5c10b5 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 194af2b9925f179eb036f2c073a65b23124323e9 Mon Sep 17 00:00:00 2001 From: Julian Wollersberger Date: Sat, 3 Oct 2020 10:46:18 +0200 Subject: [PATCH 1287/2516] Document the usage of cargo-llvm-lines and -Ztimings. --- src/doc/rustc-dev-guide/src/profiling.md | 81 +++++++++++++++++++++++- 1 file changed, 80 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index 8eaa8e94f1e6f..db5806927d48a 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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 ef29de5301c56cb2c5b12e46f26d1dc5cc745328 Mon Sep 17 00:00:00 2001 From: Julian Wollersberger Date: Sun, 4 Oct 2020 15:09:06 +0200 Subject: [PATCH 1288/2516] Did more measurements on what exactly affects llvm-lines: optimize, codegen-units and mir-opt do, but debug-assertions doesn't. --- src/doc/rustc-dev-guide/src/profiling.md | 27 ++++++++++++------------ 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index db5806927d48a..e8139dd2507e4 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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 939210d3ec1483d454fc53ec1cdbd0fac30cee0e Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Wed, 16 Sep 2020 16:04:40 -0700 Subject: [PATCH 1289/2516] add suggested workflow to setup nightly rustup for rustc --- .../rustc-dev-guide/src/building/suggested.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index cc8d92a5c10b5..a50d8a932ad26 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 512900ee697298506389685517a3e9ef71307211 Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Wed, 16 Sep 2020 16:15:39 -0700 Subject: [PATCH 1290/2516] add note --- src/doc/rustc-dev-guide/src/building/suggested.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index a50d8a932ad26..51433c5a12062 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 825b63b62b854277d7031711e8865f00ccd7293a Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Wed, 16 Sep 2020 16:42:53 -0700 Subject: [PATCH 1291/2516] Apply suggestions from code review Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/building/suggested.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 51433c5a12062..1091245ece2c3 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 6c32b8ead282e1990af6b74f37c64e1a2691a5b6 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 3 Oct 2020 19:31:44 -0500 Subject: [PATCH 1292/2516] address lingering reviewer comments --- src/doc/rustc-dev-guide/src/building/suggested.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 1091245ece2c3..112aedd981c07 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 7d32ccbc6cb85d045e271b7c9bf4c0b2598e166b Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 3 Oct 2020 19:35:37 -0500 Subject: [PATCH 1293/2516] Link to .md files, rather than .html Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/doc/rustc-dev-guide/src/building/suggested.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 112aedd981c07..2ebdecd07376b 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 32e07fe2bf108f21678dd20e9c28af08f7629234 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 4 Oct 2020 10:25:02 -0400 Subject: [PATCH 1294/2516] 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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 7116d908aa702..24f86d940b7ee 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 d66cdb10f4877ead04e4e102e36a638d69b423eb Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sun, 4 Oct 2020 16:18:37 +0200 Subject: [PATCH 1295/2516] Allow anyone to change the status of a PR --- src/doc/rustc-dev-guide/triagebot.toml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/doc/rustc-dev-guide/triagebot.toml b/src/doc/rustc-dev-guide/triagebot.toml index fa0824ac53c0a..ccb0de862ef05 100644 --- a/src/doc/rustc-dev-guide/triagebot.toml +++ b/src/doc/rustc-dev-guide/triagebot.toml @@ -1 +1,8 @@ [assign] + +[relabel] +allow-unauthenticated = [ + "waiting-on-review", + "waiting-on-author", + "blocked", +] From aeb412f6a432d3688d8de76341559765148c0982 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 4 Oct 2020 10:44:03 -0400 Subject: [PATCH 1296/2516] Document `Assemble` --- .../src/building/bootstrapping.md | 23 +++++++++++++++---- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 24f86d940b7ee..2da4d2e467ea6 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 087c400663e53c98a5b60ff2cea6fb3e1be12f2c Mon Sep 17 00:00:00 2001 From: Cass Date: Fri, 4 Sep 2020 21:13:46 -0400 Subject: [PATCH 1297/2516] 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> --- .../rustc-dev-guide/src/building/suggested.md | 26 ++++++++++++++----- 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 2ebdecd07376b..58996e639a509 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 c59789573cba164df76a2ae036ac225e84938b63 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 1298/2516] Fix typos (#916) Fixed two typos. --- src/doc/rustc-dev-guide/src/rustbot.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustbot.md b/src/doc/rustc-dev-guide/src/rustbot.md index 53211f2975bd3..8e952c3f24172 100644 --- a/src/doc/rustc-dev-guide/src/rustbot.md +++ b/src/doc/rustc-dev-guide/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 5c3780119dec66ee9811f7994835a88e8974397d Mon Sep 17 00:00:00 2001 From: Stu Date: Thu, 8 Oct 2020 17:38:40 +0200 Subject: [PATCH 1299/2516] Fix broken "system LLVM" link --- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 5837e9423910b..c13d4f0447e65 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 b3d8e18c2300befc8d6c7b13554bf52edf0c1c78 Mon Sep 17 00:00:00 2001 From: Justus K Date: Thu, 8 Oct 2020 17:41:37 +0200 Subject: [PATCH 1300/2516] Update more occurrences of system llvm link --- src/doc/rustc-dev-guide/src/building/new-target.md | 2 +- src/doc/rustc-dev-guide/src/building/prerequisites.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index 3bb77f7fc0a46..4873e66527088 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index 63d5aca8e9060..00692fda91ec6 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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 c683cf928f24412e5eef61031402d2c007f6baf1 Mon Sep 17 00:00:00 2001 From: mark Date: Mon, 5 Oct 2020 13:23:14 -0500 Subject: [PATCH 1301/2516] linkcheck only for changed files except in cron jobs --- src/doc/rustc-dev-guide/.travis.yml | 2 +- src/doc/rustc-dev-guide/book.toml | 1 + src/doc/rustc-dev-guide/ci/linkcheck.sh | 20 ++++++++++++++++++++ 3 files changed, 22 insertions(+), 1 deletion(-) create mode 100755 src/doc/rustc-dev-guide/ci/linkcheck.sh diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index fba5ab87e10c2..3e4a3dc0d3334 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 10bc2edd488fa..af909446a65cf 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh new file mode 100755 index 0000000000000..85573314c5fc1 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 fb32ba431a1384a2f0c02cd048572c9cd16d9da6 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 7 Oct 2020 03:10:35 -0500 Subject: [PATCH 1302/2516] pin mdbook-linkcheck version --- src/doc/rustc-dev-guide/.travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 3e4a3dc0d3334..395334e5c9ba3 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 9675f13c71acd0d5e99136bba94f8915489c6abd Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 7 Oct 2020 23:01:20 -0500 Subject: [PATCH 1303/2516] Add comment referring to travis docs Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/ci/linkcheck.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index 85573314c5fc1..7149ab3a7f155 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 325268f53e6cefe258348ffab1b09faee4ac81ed Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Oct 2020 15:15:58 -0500 Subject: [PATCH 1304/2516] More debuggable bash settings Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/ci/linkcheck.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index 7149ab3a7f155..a1cd424fbd9a7 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 e81601f62f8c9d29972912a9efd984d4615d96ab Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 8 Oct 2020 15:54:29 -0500 Subject: [PATCH 1305/2516] add assert --- src/doc/rustc-dev-guide/ci/linkcheck.sh | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index a1cd424fbd9a7..db6b35a5b7f21 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 ecc0b6daef7db43cb3e6c6abd12942e6e95549c4 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Oct 2020 16:08:25 -0500 Subject: [PATCH 1306/2516] Lol logic is hard Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/ci/linkcheck.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index db6b35a5b7f21..6979e98678bd5 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 8fe84e6f5e6c26b2502c5a18fd2b8087a54eaf65 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Oct 2020 16:08:42 -0500 Subject: [PATCH 1307/2516] Better error message Co-authored-by: Camelid --- src/doc/rustc-dev-guide/ci/linkcheck.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index 6979e98678bd5..d827b8476df91 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 ab08af36e1271d9c88fbb41af496b9d0cadbc052 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Thu, 8 Oct 2020 09:28:53 -0400 Subject: [PATCH 1308/2516] 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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 177fa20d208a1..0195659acb44e 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 9711293a29dcacfaae17d57696282800ad618a50 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Thu, 8 Oct 2020 00:04:54 +0200 Subject: [PATCH 1309/2516] Talk about git submodules --- src/doc/rustc-dev-guide/src/git.md | 75 ++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 633e7d5725eee..f9a6fca4429a5 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 885badd57acc9b242e67c369894cf2124f5de70a Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 10 Oct 2020 17:46:04 +0200 Subject: [PATCH 1310/2516] Apply suggestions from code review Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/git.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index f9a6fca4429a5..2d2200b3a8ef4 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 7a5a10e20315f03a60fcf651fb9e497272c14523 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 10 Oct 2020 18:35:25 +0200 Subject: [PATCH 1311/2516] Update installation instructions for `mdbook-linkcheck` --- src/doc/rustc-dev-guide/README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index aab497af30c7e..8b46b249ce5d5 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 c49644b189cfcac432bf44ece6c1fabd872ba7ec Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 11 Oct 2020 11:43:26 -0700 Subject: [PATCH 1312/2516] 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! --- src/doc/rustc-dev-guide/.travis.yml | 2 +- src/doc/rustc-dev-guide/README.md | 7 +++---- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 395334e5c9ba3..de1392e884f03 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 8b46b249ce5d5..6bd2177ed7a4b 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 9e9b8e3bc74cfa864a01ee54ba4b8aa5a2fd6637 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 11 Oct 2020 14:46:36 -0700 Subject: [PATCH 1313/2516] Mention you will need recent versions of mdbook* --- src/doc/rustc-dev-guide/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 6bd2177ed7a4b..143ecca1633e8 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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 2de5d90041cd30a43312d31834f919a2dbf7f3c2 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 1314/2516] Added description of word Scrutinee to the glossary (#921) --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 007edce8d54fd..842613d257c17 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 8263e7e082fb89a2d864d4d5076639b4c674955d Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 16 Oct 2020 12:00:19 +0900 Subject: [PATCH 1315/2516] Fix a link on git.md --- src/doc/rustc-dev-guide/src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 2d2200b3a8ef4..f567188de7d17 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 f1e6f2d3f9f42548e0d32b817ec3a17a04232b12 Mon Sep 17 00:00:00 2001 From: Nadrieril Date: Fri, 16 Oct 2020 21:59:28 +0100 Subject: [PATCH 1316/2516] Explain pattern exhaustiveness checking --- .../src/pat-exhaustive-checking.md | 82 ++++++++++++++++++- 1 file changed, 81 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md b/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md index b29bb1351e8a6..da4dab3bfd436 100644 --- a/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md +++ b/src/doc/rustc-dev-guide/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 70373f2135cee18575fd0f14ddba63811c286192 Mon Sep 17 00:00:00 2001 From: Nadrieril Date: Fri, 16 Oct 2020 22:48:00 +0100 Subject: [PATCH 1317/2516] Explain why exhaustiveness is necessary for soundness --- src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md b/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md index da4dab3bfd436..767b7de507fac 100644 --- a/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md +++ b/src/doc/rustc-dev-guide/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 0b76e4986f056cdedc3959cbeb738f74b31f782c Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 19 Oct 2020 15:00:49 -0300 Subject: [PATCH 1318/2516] Fix typo errros -> errors --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 7f704d05db69c..a02b854af20b7 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 3491394b55fc279ced0f73ad6456838072964ca5 Mon Sep 17 00:00:00 2001 From: Ivan Tham Date: Tue, 20 Oct 2020 10:03:42 +0800 Subject: [PATCH 1319/2516] Remove outdated build rustdoc --stage 1 It builds with stage 1 by default. --- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index f9c37ecd4a66e..bfe2912291bb5 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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 3867cc04d050312ff6178a66950820d8323806fc Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 19 Oct 2020 22:31:34 -0400 Subject: [PATCH 1320/2516] Revert "Remove outdated build rustdoc --stage 1" This reverts commit cd35d2b5944d8436350b7f2f16f5e720d9912db6. --- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index bfe2912291bb5..f9c37ecd4a66e 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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 8f77e5006119710e6e8b6de544002fcc7e14daea Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 22 Oct 2020 04:26:40 +0900 Subject: [PATCH 1321/2516] Replace links to `buildbot2.r-l.o` with `bors.r-l.o` --- src/doc/rustc-dev-guide/src/compiler-team.md | 2 +- src/doc/rustc-dev-guide/src/contributing.md | 4 ++-- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- src/doc/rustc-dev-guide/src/tests/intro.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index 33ff65af604d0..ebb8cbc166150 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 5dd80c93349e6..fb65a8eae0400 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index c13d4f0447e65..6ca7f1edabd78 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 3503e7ad10b44..3be9219f61483 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 d26d3ea29e31bf2d255b7ee98006e7f2d4fb90b0 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 22 Oct 2020 06:53:32 +0900 Subject: [PATCH 1322/2516] Add reference PRs for `r?` and `r+` comments (#928) --- src/doc/rustc-dev-guide/src/getting-started.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 6ca7f1edabd78..da444cdbb0535 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 9354c4f98beb338ada1b2da59c5858ba222aca1b Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 21 Oct 2020 18:25:54 -0400 Subject: [PATCH 1323/2516] 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: ``` --- src/doc/rustc-dev-guide/ci/check-in.sh | 34 ++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100755 src/doc/rustc-dev-guide/ci/check-in.sh diff --git a/src/doc/rustc-dev-guide/ci/check-in.sh b/src/doc/rustc-dev-guide/ci/check-in.sh new file mode 100755 index 0000000000000..d41a7ae5780da --- /dev/null +++ b/src/doc/rustc-dev-guide/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 7eb38c2b8cd6be1ff2b514231d4b6d90862dace1 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 21 Oct 2020 18:38:38 -0400 Subject: [PATCH 1324/2516] Improve markdown formatting --- src/doc/rustc-dev-guide/ci/check-in.sh | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/check-in.sh b/src/doc/rustc-dev-guide/ci/check-in.sh index d41a7ae5780da..694c3bdf82270 100755 --- a/src/doc/rustc-dev-guide/ci/check-in.sh +++ b/src/doc/rustc-dev-guide/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 3ed54a3ff68ddbe2348ae9bfab23c695d9df9538 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 21 Oct 2020 20:15:55 -0400 Subject: [PATCH 1325/2516] fix formatting --- src/doc/rustc-dev-guide/ci/check-in.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/check-in.sh b/src/doc/rustc-dev-guide/ci/check-in.sh index 694c3bdf82270..ef61b68715d48 100755 --- a/src/doc/rustc-dev-guide/ci/check-in.sh +++ b/src/doc/rustc-dev-guide/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 7de7a026338e4f81d699222ca5aed009ff742aa8 Mon Sep 17 00:00:00 2001 From: Nadrieril Date: Thu, 22 Oct 2020 21:28:41 +0100 Subject: [PATCH 1326/2516] Explain lint renaming/removing --- src/doc/rustc-dev-guide/src/diagnostics.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index a3293101fe617..04745ee981908 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 c83287980df5646d67fc8ff79c88dc1526923529 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 26 Oct 2020 08:15:21 +0900 Subject: [PATCH 1327/2516] 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/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index 00692fda91ec6..ebbe13ce484ec 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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 c68119c8d28c060197ffd962e19928facebeb33f Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 25 Oct 2020 19:58:00 -0700 Subject: [PATCH 1328/2516] Clean up `compiletest` chapter (#935) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- src/doc/rustc-dev-guide/src/compiletest.md | 104 ++++++++++----------- 2 files changed, 52 insertions(+), 54 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index f3ebe4da80fbc..41de149544b77 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index dbd6c4b6e1859..2e0bcec538bda 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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 e6b6363cc082b57f761c964d82eebb09ee5517da Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 27 Oct 2020 11:30:20 -0700 Subject: [PATCH 1329/2516] Add "ctxt" and `TyCtxt` to the glossary (#937) --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 842613d257c17..84fff5e79665f 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 b6c5a153bfb084ea556175f0a71b4b35614afe6b Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 27 Oct 2020 18:34:28 +0000 Subject: [PATCH 1330/2516] Small improvements (#936) * Fix typo errros -> errors * an -> a * hir -> hir() --- src/doc/rustc-dev-guide/src/hir.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 5757d1e778669..a88ba90666561 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 985668662c9e61423abdb8dd987098839a1946f6 Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 27 Oct 2020 12:26:08 -0700 Subject: [PATCH 1331/2516] Fix broken tags in glossary --- .../rustc-dev-guide/src/appendix/glossary.md | 176 +++++++++--------- 1 file changed, 88 insertions(+), 88 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 84fff5e79665f..5a1c5c16bbd19 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 361333ab24ba231e771b4bf97725704470f9da15 Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 27 Oct 2020 12:25:04 -0700 Subject: [PATCH 1332/2516] Put `TyCtxt` at the right position It should now be at its alphabetical position. Also fixed link to `TyCtxt` anchor. --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 5a1c5c16bbd19..fb216c4f98e3b 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 8178320c279aacfa61eace734d9bbe2359476980 Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 27 Oct 2020 17:32:06 -0700 Subject: [PATCH 1333/2516] Use new-style mdBook internal links in glossary --- .../rustc-dev-guide/src/appendix/glossary.md | 60 +++++++++---------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index fb216c4f98e3b..58ec39e4fb11c 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 4723ff1be43762e532d201a2daa42796ceb71cb0 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 2 Nov 2020 22:52:28 +0900 Subject: [PATCH 1334/2516] Use `provide_both` link instead of `provide(_extern)` --- src/doc/rustc-dev-guide/src/query.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 52786ad342546..77d3b50e5c253 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 6e9d316e14f2bb5d106ae084c44ec1c412164fd1 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 1335/2516] correct minor grammar mistake (#944) correct `a lots to `a lot` on implementing_new_features.md --- src/doc/rustc-dev-guide/src/implementing_new_features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 2103c8803cfb6..baf4e2b515d31 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 9c0b661c4966edc0507b839e38fc717e683a56cf Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sun, 8 Nov 2020 14:46:41 -0800 Subject: [PATCH 1336/2516] 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. --- .../rustc-dev-guide/src/building/how-to-build-and-run.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 0195659acb44e..39d7e9a4c0beb 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 6b132a0494effc3bcd1f08ac1df5c89225d575aa Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sun, 8 Nov 2020 14:51:46 -0800 Subject: [PATCH 1337/2516] Fix install command --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 39d7e9a4c0beb..bf9fd5b33fc08 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 2638846c4993887d5646e70fc43dd2c5c53ade22 Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sun, 8 Nov 2020 16:20:37 -0800 Subject: [PATCH 1338/2516] Update src/building/how-to-build-and-run.md Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index bf9fd5b33fc08..a97568e6eb25e 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 ad2ef2af6b3b712f0317bd6ef318768095107625 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 10 Nov 2020 16:23:35 -0500 Subject: [PATCH 1339/2516] 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/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs index e33c2ee9571a4..8ee38206f7c4b 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs +++ b/src/doc/rustc-dev-guide/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 a179f33191bd91c323dc9f3ed97c75e54fe2e0fc Mon Sep 17 00:00:00 2001 From: Olivier FAURE Date: Wed, 11 Nov 2020 12:31:58 +0000 Subject: [PATCH 1340/2516] 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/doc/rustc-dev-guide/src/compiler-debugging.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index e4b04aa969205..914aee1bc9bd5 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 c52906f46da95f4281f367634029892c2421bc7f Mon Sep 17 00:00:00 2001 From: Olivier FAURE Date: Wed, 11 Nov 2020 14:58:56 +0000 Subject: [PATCH 1341/2516] Update src/compiler-debugging.md Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 914aee1bc9bd5..4b241d8ea691d 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 d268f498506ccb96da78e5693ad67304f154fb60 Mon Sep 17 00:00:00 2001 From: Alexis Bourget Date: Thu, 12 Nov 2020 00:45:34 +0100 Subject: [PATCH 1342/2516] Links to htmldocck/@has/matches for searchability --- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index f9c37ecd4a66e..1f7f100459612 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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 8b427d53d3245c88056c9f72044ae2599323742c Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 10 Nov 2020 16:22:45 -0800 Subject: [PATCH 1343/2516] Add a section on data-flow convergence --- src/doc/rustc-dev-guide/src/mir/dataflow.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index bc65ecfa2741b..061ea90382cb5 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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 671e815240d74ed869bf512e09cc8cff3e73d82a Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 10 Nov 2020 17:41:40 -0800 Subject: [PATCH 1344/2516] Explain the purpose of the bottom value --- src/doc/rustc-dev-guide/src/mir/dataflow.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index 061ea90382cb5..2bf293cc1278f 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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 6eafb25a51c8180285f159881238fe8af416bfce Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 11 Nov 2020 12:48:15 -0800 Subject: [PATCH 1345/2516] Provide a brief example of a data-flow analysis --- src/doc/rustc-dev-guide/src/mir/dataflow.md | 26 +++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index 2bf293cc1278f..b5cbd46868a78 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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 56d55dda66a2d1b3826aebc34016d0f54cf98351 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 1346/2516] add string interning wikipedia link (#960) --- src/doc/rustc-dev-guide/src/overview.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index baa1e0aa635cf..82f2289e47486 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 680c1317e618e15b96d43b618a61aa7797715831 Mon Sep 17 00:00:00 2001 From: Tobias Date: Mon, 16 Nov 2020 18:38:14 +0100 Subject: [PATCH 1347/2516] updated link for Citizen Code of Conduct (#959) * remove the code of conduct; instead link to https://www.rust-lang.org/conduct.html --- src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md | 37 +--------------------- 1 file changed, 1 insertion(+), 36 deletions(-) diff --git a/src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md b/src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md index 89a9cdfcce074..42f287fbbc830 100644 --- a/src/doc/rustc-dev-guide/CODE_OF_CONDUCT.md +++ b/src/doc/rustc-dev-guide/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 462fd32ac3a7151ff0498112dc1c5ef39b724908 Mon Sep 17 00:00:00 2001 From: cjkenn Date: Fri, 20 Nov 2020 12:09:37 -0500 Subject: [PATCH 1348/2516] add mir-opt section for optimization fuel --- .../rustc-dev-guide/src/mir/optimizations.md | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index 65323ed52e488..b34520f353d99 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 157db48097637eec482abac07551033dea57b2e1 Mon Sep 17 00:00:00 2001 From: cjkenn Date: Fri, 20 Nov 2020 14:51:29 -0500 Subject: [PATCH 1349/2516] add small explanation of why fuel can be useful for debugging --- src/doc/rustc-dev-guide/src/mir/optimizations.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index b34520f353d99..080c8fd3fb044 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 36fb53e9843d927a2b8f81c711e67d3c1d2bb09b Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 23 Nov 2020 15:10:44 -0800 Subject: [PATCH 1350/2516] 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/doc/rustc-dev-guide/src/param_env.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/param_env.md b/src/doc/rustc-dev-guide/src/param_env.md index aa6d6e2155c15..9050c5c79d6e5 100644 --- a/src/doc/rustc-dev-guide/src/param_env.md +++ b/src/doc/rustc-dev-guide/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 805527920933667cf40e894b786962189f616fef Mon Sep 17 00:00:00 2001 From: mark Date: Mon, 23 Nov 2020 14:49:04 -0600 Subject: [PATCH 1351/2516] don't use cache while running PR builds --- src/doc/rustc-dev-guide/.travis.yml | 2 +- src/doc/rustc-dev-guide/ci/linkcheck.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index de1392e884f03..f503eeefa028b 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index d827b8476df91..41cb6a35e4593 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 baf801c294e09b1ce809307c7d3beeeb0e88fcf1 Mon Sep 17 00:00:00 2001 From: Gabriel de Perthuis Date: Tue, 24 Nov 2020 12:20:16 +0100 Subject: [PATCH 1352/2516] Update bootstrap documentation with the new envvars for RUSTFLAGS This follows . --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 2da4d2e467ea6..0921755a06533 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 4340f6dc8bac6fa937baeb5da2076c1b3007a766 Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 24 Nov 2020 17:09:59 -0800 Subject: [PATCH 1353/2516] Document when errors should have an associated error code (#967) Document when errors should have an associated error code --- src/doc/rustc-dev-guide/src/diagnostics.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 04745ee981908..fe75c22151fcf 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 748176738451f87e5b11125dbcefb7b56c5fa81d Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 23 Nov 2020 14:37:10 -0800 Subject: [PATCH 1354/2516] Document how to modify feature gates How to remove them and how to rename them. cc cc @varkor --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/feature-gates.md | 65 ++++++++++++++++++++ 2 files changed, 66 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/feature-gates.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 41de149544b77..62081cd565dec 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/feature-gates.md b/src/doc/rustc-dev-guide/src/feature-gates.md new file mode 100644 index 0000000000000..b4aae0443dc4e --- /dev/null +++ b/src/doc/rustc-dev-guide/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 9d811ab8376c050bed08f10a379472b7a361f254 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 23 Nov 2020 15:59:15 -0800 Subject: [PATCH 1355/2516] Move instructions for adding a feature gate to "Feature Gates" --- src/doc/rustc-dev-guide/src/feature-gates.md | 35 +++++++++++++++++-- .../src/implementing_new_features.md | 22 ++---------- 2 files changed, 35 insertions(+), 22 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/feature-gates.md b/src/doc/rustc-dev-guide/src/feature-gates.md index b4aae0443dc4e..b81721edcd504 100644 --- a/src/doc/rustc-dev-guide/src/feature-gates.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index baf4e2b515d31..3a65f15e75146 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 b417b9ed300adc28b847400d84d9437d88dd0f61 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 23 Nov 2020 16:06:24 -0800 Subject: [PATCH 1356/2516] Link to feature-stabilization docs --- src/doc/rustc-dev-guide/src/feature-gates.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/feature-gates.md b/src/doc/rustc-dev-guide/src/feature-gates.md index b81721edcd504..db6c72ff81093 100644 --- a/src/doc/rustc-dev-guide/src/feature-gates.md +++ b/src/doc/rustc-dev-guide/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 a58c08ef1b5280d5b537655259b166d8e89dc0d8 Mon Sep 17 00:00:00 2001 From: Hirochika Matsumoto Date: Sun, 29 Nov 2020 04:02:07 +0900 Subject: [PATCH 1357/2516] Fix a typo --- src/doc/rustc-dev-guide/src/compiler-src.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 5183a7c85b8bd..b26ede5799bc9 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 2b511d9e0d9900ae336a71ee0a63cb2d01297449 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 29 Nov 2020 09:46:27 -0500 Subject: [PATCH 1358/2516] Add information about common git issues --- src/doc/rustc-dev-guide/src/git.md | 51 +++++++++++++++++++++++++++++- 1 file changed, 50 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index f567188de7d17..b4968df815f53 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 004d030e522b95550fb5ad0da21294956cc58316 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 29 Nov 2020 10:32:07 -0500 Subject: [PATCH 1359/2516] Don't imply that the name of the fork always needs to be changed --- src/doc/rustc-dev-guide/src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index b4968df815f53..d1e6b8c41ee06 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 9c0ed53e94258a2adc9a2d46a4c004ecdf4365b1 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 29 Nov 2020 10:20:24 -0500 Subject: [PATCH 1360/2516] Document what 'sysroot' means --- .../rustc-dev-guide/src/appendix/glossary.md | 1 + .../src/building/bootstrapping.md | 59 +++++++++++++++++++ 2 files changed, 60 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 58ec39e4fb11c..8ecd4f6158b2b 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 0921755a06533..1d420a978df6b 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 76ac4633fea78fa1c5eafd4a8ccd21979e5e1b92 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 30 Nov 2020 09:08:32 -0500 Subject: [PATCH 1361/2516] 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 --- src/doc/rustc-dev-guide/README.md | 67 ++++--------------------- src/doc/rustc-dev-guide/ci/linkcheck.sh | 4 +- 2 files changed, 14 insertions(+), 57 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 143ecca1633e8..5448ca9bbc03b 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index 41cb6a35e4593..d329a71642e58 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 3ae060dbfc1eb1ce431f6abc054754f472b6073e Mon Sep 17 00:00:00 2001 From: Ben Striegel Date: Sun, 29 Nov 2020 12:38:44 -0500 Subject: [PATCH 1362/2516] Add notes about running the UI test suite --- src/doc/rustc-dev-guide/src/tests/running.md | 37 ++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 5e18b8a95992c..15f11cb472dcf 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 7aadeecb5e18be35762632c221ff0f7dbcc7ffe0 Mon Sep 17 00:00:00 2001 From: Ben Striegel Date: Mon, 30 Nov 2020 18:02:07 -0500 Subject: [PATCH 1363/2516] Address feedback --- src/doc/rustc-dev-guide/src/tests/running.md | 52 ++++++-------------- 1 file changed, 15 insertions(+), 37 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 15f11cb472dcf..4fe61f30a931e 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 0cf6b13c5424552fc8d372e499d989eccefb3c01 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 30 Nov 2020 18:08:17 -0500 Subject: [PATCH 1364/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 62081cd565dec..fbeedbe15452c 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 c5545f8dd98d4aa69b196b7c98082a14d7531e48 Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 1 Dec 2020 10:52:02 -0800 Subject: [PATCH 1365/2516] Use shorter 'rustbot label' command 'rustbot modify labels: ...' -> 'rustbot label ...' --- src/doc/rustc-dev-guide/src/rustbot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustbot.md b/src/doc/rustc-dev-guide/src/rustbot.md index 8e952c3f24172..5350f44efb4ae 100644 --- a/src/doc/rustc-dev-guide/src/rustbot.md +++ b/src/doc/rustc-dev-guide/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 ca6075eb909424bcb7aa813568782809dbf4a61f Mon Sep 17 00:00:00 2001 From: jumbatm Date: Mon, 16 Nov 2020 17:48:41 +1000 Subject: [PATCH 1366/2516] Document SessionDiagnostic --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/diagnostics.md | 4 + .../src/diagnostics/sessiondiagnostic.md | 97 +++++++++++++++++++ 3 files changed, 102 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index fbeedbe15452c..43df9bdb5edcc 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index fe75c22151fcf..f9217785d3744 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md b/src/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md new file mode 100644 index 0000000000000..b64c620071d89 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 b2eb38e362a757a0db5a7de665dc65b63b4a80fc Mon Sep 17 00:00:00 2001 From: jumbatm Date: Mon, 16 Nov 2020 17:48:41 +1000 Subject: [PATCH 1367/2516] Apply suggestions from review. Co-authored-by: Camelid --- .../rustc-dev-guide/src/diagnostics/sessiondiagnostic.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md b/src/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md index b64c620071d89..4583e6d3dc953 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md +++ b/src/doc/rustc-dev-guide/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 9d576c9ef1eb829939b7cbf91bae95b45a2f765c Mon Sep 17 00:00:00 2001 From: jumbatm Date: Mon, 16 Nov 2020 17:48:41 +1000 Subject: [PATCH 1368/2516] Use shorter [][]-style link to not pass 100 chars. --- src/doc/rustc-dev-guide/src/diagnostics.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index f9217785d3744..fce79d725b7cc 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 5da3f6499216b9f7d4994869d84db1cf095b7695 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 2 Dec 2020 22:37:22 -0600 Subject: [PATCH 1369/2516] exclude play.rlo from linkchecks --- src/doc/rustc-dev-guide/book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index af909446a65cf..af9cd167fdcd5 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 cb2ea72e78b1214ba966ec697c22a817ec530135 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 2 Dec 2020 22:40:36 -0600 Subject: [PATCH 1370/2516] fix a couple links --- src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md | 8 ++++---- src/doc/rustc-dev-guide/src/traits/hrtb.md | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md b/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md index 767b7de507fac..a3103de8fde2a 100644 --- a/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/hrtb.md b/src/doc/rustc-dev-guide/src/traits/hrtb.md index c0ca318e6e2d0..aa85448afea5c 100644 --- a/src/doc/rustc-dev-guide/src/traits/hrtb.md +++ b/src/doc/rustc-dev-guide/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 7cf284df457c5bfcc3a58b26245d073f3bf8a67a Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Fri, 4 Dec 2020 12:23:46 -0500 Subject: [PATCH 1371/2516] 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/doc/rustc-dev-guide/src/rustdoc.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index b37c15808cfe4..c087689d9b43a 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 51936d51e81637bfd5d528b3e248f7c22b90f6c2 Mon Sep 17 00:00:00 2001 From: Siddharth Date: Sun, 6 Dec 2020 19:10:45 +0530 Subject: [PATCH 1372/2516] 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/doc/rustc-dev-guide/src/mir/index.md | 33 ++++++++++++++++-------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index f771fa0ede533..df47151a3ea31 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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 599a755bb6135f27fb27fabffb7a1a8a6d22ca49 Mon Sep 17 00:00:00 2001 From: Siddharth Date: Sun, 6 Dec 2020 20:06:52 +0530 Subject: [PATCH 1373/2516] 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/doc/rustc-dev-guide/src/mir/index.md | 29 ++++++++++++++---------- 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index df47151a3ea31..55a4a434991b6 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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 85771c7af946ff0e3898fadb5138fe02379104cd Mon Sep 17 00:00:00 2001 From: Rich Kadel Date: Sun, 6 Dec 2020 13:58:29 -0800 Subject: [PATCH 1374/2516] Adds a dev guide section on Rust Coverage --- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/img/coverage-branch-counting-01.png create mode 100644 src/doc/rustc-dev-guide/src/img/coverage-graphviz-01.png create mode 100644 src/doc/rustc-dev-guide/src/img/coverage-spanview-01.png create mode 100644 src/doc/rustc-dev-guide/src/img/llvm-cov-show-01.png create mode 100644 src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 43df9bdb5edcc..9a695c94d6da6 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/img/coverage-branch-counting-01.png b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/img/coverage-spanview-01.png b/src/doc/rustc-dev-guide/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 4fb8877909ca44608110fd0d16e4c15e3a0629f0 Mon Sep 17 00:00:00 2001 From: Chayim Refael Friedman Date: Tue, 9 Mar 2021 19:16:46 +0200 Subject: [PATCH 1441/2516] Fix typo: suceed -> succeed --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 352d826d337c4..7385cefb38449 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 b818c60727459c2df57319eee4c9a28c01691c01 Mon Sep 17 00:00:00 2001 From: Wesley Wiser Date: Tue, 9 Mar 2021 14:00:12 -0500 Subject: [PATCH 1442/2516] Update cmake version in prerequisites.md (#1077) LLVM requires at least cmake 3.13.4. https://www.llvm.org/docs/CMake.html --- src/doc/rustc-dev-guide/src/building/prerequisites.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index ebbe13ce484ec..f7f47d40c58ab 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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 7268344274da337ef0acbe61ba768694a57b4118 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 10 Mar 2021 11:56:51 -0300 Subject: [PATCH 1443/2516] Fix typos (#1079) --- .../borrow_check/region_inference/placeholders_and_universes.md | 2 +- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md index 20775038be44a..e1c28ba4c54e7 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index d0c77edf26bed..9db77fcb613ae 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 1d6e82fe0a0c39b0d6d904439feace9fee4360d6 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 10 Mar 2021 12:04:40 -0300 Subject: [PATCH 1444/2516] Adjust a bit better P- label text --- src/doc/rustc-dev-guide/src/contributing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 9db77fcb613ae..c4a3fe872a7a4 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 e33049fc64dd5fd87a9c5190326ceee5f3ef1fb0 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 11 Mar 2021 01:51:56 +0900 Subject: [PATCH 1445/2516] Switch from Travis to GHA (#1073) --- .../rustc-dev-guide/.github/workflows/ci.yml | 77 +++++++++++++++++++ src/doc/rustc-dev-guide/.travis.yml | 39 ---------- src/doc/rustc-dev-guide/ci/linkcheck.sh | 12 +-- 3 files changed, 83 insertions(+), 45 deletions(-) create mode 100644 src/doc/rustc-dev-guide/.github/workflows/ci.yml delete mode 100644 src/doc/rustc-dev-guide/.travis.yml diff --git a/src/doc/rustc-dev-guide/.github/workflows/ci.yml b/src/doc/rustc-dev-guide/.github/workflows/ci.yml new file mode 100644 index 0000000000000..c3307bb74d0ff --- /dev/null +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml deleted file mode 100644 index 1d67472583c58..0000000000000 --- a/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index d329a71642e58..3d70432f5cfbd 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 d1875c755c6d6f527c032e3435f4957086dbb40b Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Mon, 8 Mar 2021 23:32:09 +0100 Subject: [PATCH 1446/2516] Add stub about the THIR --- src/doc/rustc-dev-guide/src/SUMMARY.md | 3 +- .../rustc-dev-guide/src/mir/construction.md | 22 ++--------- src/doc/rustc-dev-guide/src/thir.md | 39 +++++++++++++++++++ 3 files changed, 45 insertions(+), 19 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/thir.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 24117886466a4..3f14c2642173e 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index d2c5a6f3442c1..d9f99be033e28 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/thir.md b/src/doc/rustc-dev-guide/src/thir.md new file mode 100644 index 0000000000000..04bf635ceb73a --- /dev/null +++ b/src/doc/rustc-dev-guide/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 a937cf6355c9fd0520d0dd382a755ad50ff24617 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 1447/2516] Apply suggestions from code review Co-authored-by: Camelid --- src/doc/rustc-dev-guide/src/thir.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/thir.md b/src/doc/rustc-dev-guide/src/thir.md index 04bf635ceb73a..efbc5284916c6 100644 --- a/src/doc/rustc-dev-guide/src/thir.md +++ b/src/doc/rustc-dev-guide/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 19c59cd26f6e8d1d6dbc535b4d025704c12f8f10 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 1448/2516] Update lins --- src/doc/rustc-dev-guide/src/thir.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/thir.md b/src/doc/rustc-dev-guide/src/thir.md index efbc5284916c6..b023eb2e2a1cb 100644 --- a/src/doc/rustc-dev-guide/src/thir.md +++ b/src/doc/rustc-dev-guide/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 613c370d294c88ec939be41ccca3fa0341c77fd7 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 11 Mar 2021 23:50:34 +0900 Subject: [PATCH 1449/2516] Check `BASE_SHA` only if it's a PR (#1083) --- src/doc/rustc-dev-guide/ci/linkcheck.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index 3d70432f5cfbd..8848235480429 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 c270c49c6b4bd687d25e77b6aa741a56f0dc101f Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 11 Mar 2021 14:55:41 -0300 Subject: [PATCH 1450/2516] Complete unfinished statement --- src/doc/rustc-dev-guide/src/git.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index d906199483630..e533426cfca66 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 61f37995fab2cc0e63d52fd151d760297f1a3e20 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 11 Mar 2021 15:05:02 -0300 Subject: [PATCH 1451/2516] 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/doc/rustc-dev-guide/src/contributing.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index c4a3fe872a7a4..abe1bb8390b98 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 1ff29a60fec96b6a05e639e3ff783d67e16a2e06 Mon Sep 17 00:00:00 2001 From: Camelid Date: Thu, 11 Mar 2021 10:29:19 -0800 Subject: [PATCH 1452/2516] 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 +- .../borrow_check/region_inference/placeholders_and_universes.md | 2 +- src/doc/rustc-dev-guide/src/mir/dataflow.md | 2 +- src/doc/rustc-dev-guide/src/param_env.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index 9e22aabc956a4..dfc4327e501df 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md index e1c28ba4c54e7..967aa0d336dbb 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index 9958f19b999f2..61277846ba294 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/param_env.md b/src/doc/rustc-dev-guide/src/param_env.md index 9050c5c79d6e5..08e19c339bb5b 100644 --- a/src/doc/rustc-dev-guide/src/param_env.md +++ b/src/doc/rustc-dev-guide/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 9cdaf686e797689d3b29faeeac395d9d3fd7f748 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 11 Mar 2021 18:36:25 -0300 Subject: [PATCH 1453/2516] Remove extra the (#1088) --- src/doc/rustc-dev-guide/src/early-late-bound.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/early-late-bound.md b/src/doc/rustc-dev-guide/src/early-late-bound.md index 973306b86ae94..4178a4af0590c 100644 --- a/src/doc/rustc-dev-guide/src/early-late-bound.md +++ b/src/doc/rustc-dev-guide/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 ccfbec360a8922e450d883e8edcf014d72979ffa Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 19 Mar 2021 20:11:43 -0300 Subject: [PATCH 1454/2516] 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/doc/rustc-dev-guide/src/compiler-team.md | 42 +++++++++++--------- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index ebb8cbc166150..8cfcc5bb66707 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 2351ca9755d322055a8f542e8cfa1aaad06963c5 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 1455/2516] Update rustc-driver-*.rs examples (#1095) --- .../rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs index f01072b7beabf..51af6f5aab2a2 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs index e1caab326b7d0..ee9a20c059513 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs index 8ee38206f7c4b..2c7533498078a 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs +++ b/src/doc/rustc-dev-guide/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 db8d6f10e2939a2bb31f0a6e691da4705eed684b Mon Sep 17 00:00:00 2001 From: JohnTitor Date: Sun, 28 Mar 2021 20:01:00 +0900 Subject: [PATCH 1456/2516] 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/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md b/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md index 27ca2ca12b8fa..fa5ce0750efd5 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md b/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md index 21d03bbb7403d..7cb53187b25f6 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md +++ b/src/doc/rustc-dev-guide/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 7c648c34cd1a2945b14af56698b49bc2f4bd6871 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 31 Mar 2021 12:25:14 -0400 Subject: [PATCH 1457/2516] Document test input normalization --- src/doc/rustc-dev-guide/src/tests/adding.md | 22 ++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 944b895b52a5b..656d0095f0992 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 2f310e57814b55df97230a1c9c3ef4728c450eee Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 31 Mar 2021 15:04:46 -0400 Subject: [PATCH 1458/2516] Add back example of {{cwd}} (#1099) I force-pushed this in the last commit and accidentally deleted the github suggestion. --- src/doc/rustc-dev-guide/src/tests/adding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 656d0095f0992..8508c2f206d60 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 3f1d3e0769bcef6e68c27a0814fe64a6b26d65f6 Mon Sep 17 00:00:00 2001 From: Camelid Date: Thu, 1 Apr 2021 10:24:44 -0700 Subject: [PATCH 1459/2516] Add quickstart for adding a new optimization (#1094) --- .../rustc-dev-guide/src/mir/optimizations.md | 49 +++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index 080c8fd3fb044..50e06960ed592 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 b17f1e72aef1691717e05ad3210b328d0e7f8798 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 2 Apr 2021 18:12:42 +0900 Subject: [PATCH 1460/2516] Fix a link about Rustdoc internals --- src/doc/rustc-dev-guide/src/rustdoc.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 33f2c5f357194..b0c68aa9d5e90 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 0686ce5a942d0343d25034474857a785b1701162 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 2 Apr 2021 05:15:48 +0900 Subject: [PATCH 1461/2516] Update the "LLVM updates" section --- .../src/backend/updating-llvm.md | 20 +++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md b/src/doc/rustc-dev-guide/src/backend/updating-llvm.md index a9c3b45c41466..9deff62dd6fa8 100644 --- a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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 0eae82a6549a40b5acb34cc87c464d3eed8b2476 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 1462/2516] Fix rustdocs test command typo (#1103) --- src/doc/rustc-dev-guide/src/rustdoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index b0c68aa9d5e90..88177ccba81ba 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 c13d2dc3722d18513da88baaaceffec2945db06d Mon Sep 17 00:00:00 2001 From: AngelicosPhosphoros Date: Sun, 4 Apr 2021 03:13:03 +0300 Subject: [PATCH 1463/2516] Mention CI build of LLVM in build instruction --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index a97568e6eb25e..77f36cda86cfc 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 b4fccbc47a911dffc4392be018120b616286dee0 Mon Sep 17 00:00:00 2001 From: Waffle Lapkin Date: Fri, 9 Apr 2021 00:21:22 +0300 Subject: [PATCH 1464/2516] fix typo --- src/doc/rustc-dev-guide/src/generics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/generics.md b/src/doc/rustc-dev-guide/src/generics.md index cdbf63b9307ee..c7a0be09355df 100644 --- a/src/doc/rustc-dev-guide/src/generics.md +++ b/src/doc/rustc-dev-guide/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 dd25839327a4ef608f0942c3c46728924a107306 Mon Sep 17 00:00:00 2001 From: Waffle Lapkin Date: Fri, 9 Apr 2021 13:30:04 +0300 Subject: [PATCH 1465/2516] fix typo (#1107) --- src/doc/rustc-dev-guide/src/method-lookup.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/method-lookup.md b/src/doc/rustc-dev-guide/src/method-lookup.md index 5aafb6abf04e3..43310556338ed 100644 --- a/src/doc/rustc-dev-guide/src/method-lookup.md +++ b/src/doc/rustc-dev-guide/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 1ddb35a6c7c604a8e1c22f5ac2ab92ffea8f5226 Mon Sep 17 00:00:00 2001 From: Waffle Lapkin Date: Fri, 9 Apr 2021 17:27:03 +0300 Subject: [PATCH 1466/2516] Change wording a bit: `module` => `crate` It seems more correct --- src/doc/rustc-dev-guide/src/method-lookup.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/method-lookup.md b/src/doc/rustc-dev-guide/src/method-lookup.md index 43310556338ed..17116406ce527 100644 --- a/src/doc/rustc-dev-guide/src/method-lookup.md +++ b/src/doc/rustc-dev-guide/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 ed653af813ac97104d799c93e48817ebce7b2f07 Mon Sep 17 00:00:00 2001 From: Camelid Date: Fri, 9 Apr 2021 14:25:18 -0700 Subject: [PATCH 1467/2516] Improve formatting and update info in "method lookup" section --- src/doc/rustc-dev-guide/src/method-lookup.md | 33 +++++++------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/method-lookup.md b/src/doc/rustc-dev-guide/src/method-lookup.md index 17116406ce527..250eea034f1dd 100644 --- a/src/doc/rustc-dev-guide/src/method-lookup.md +++ b/src/doc/rustc-dev-guide/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 25580bb38ef093a8a03fd65331e8af2e5561ccca Mon Sep 17 00:00:00 2001 From: Smitty Date: Fri, 23 Apr 2021 16:14:57 -0400 Subject: [PATCH 1468/2516] Mention unpretty=mir-cfg for debugging MIR --- src/doc/rustc-dev-guide/src/mir/debugging.md | 5 + src/doc/rustc-dev-guide/src/mir/mir_cfg.svg | 270 +++++++++++++++++++ 2 files changed, 275 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/mir/mir_cfg.svg diff --git a/src/doc/rustc-dev-guide/src/mir/debugging.md b/src/doc/rustc-dev-guide/src/mir/debugging.md index c6734f8aaae65..b7182fa900ec4 100644 --- a/src/doc/rustc-dev-guide/src/mir/debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/mir_cfg.svg b/src/doc/rustc-dev-guide/src/mir/mir_cfg.svg new file mode 100644 index 0000000000000..70705ec0430b3 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 e8e6098673e6f1b1cc5a8323999b9571e2eaf533 Mon Sep 17 00:00:00 2001 From: Nixon Enraght-Moony Date: Sat, 24 Apr 2021 02:53:30 +0100 Subject: [PATCH 1469/2516] Add Polymorphisation paper (#1093) --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index c8b4a23b345d3..0caed3fafbb14 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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 3da52a13ca36d32e2444f7110eb9f963df12b002 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Tue, 27 Apr 2021 00:34:50 +0200 Subject: [PATCH 1470/2516] more RA config suggestions (#1114) --- src/doc/rustc-dev-guide/src/building/suggested.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 6e0f830c65a8b..ebefd61c1365c 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 f4253418965d62276ae24e4f1825b055a7beccf0 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 25 Apr 2021 11:24:16 -0400 Subject: [PATCH 1471/2516] 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 ++--- .../rustc-dev-guide/src/building/suggested.md | 71 +++++++++++++++++++ 2 files changed, 77 insertions(+), 13 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 77f36cda86cfc..49c2e8b6649f1 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index ebefd61c1365c..f27793140d380 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 cadc25ff9b9ddc3f6b33fb7c07793c37eac6f788 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 12 Mar 2021 08:21:10 +0900 Subject: [PATCH 1472/2516] Trigger GHA only on the original repo --- src/doc/rustc-dev-guide/.github/workflows/ci.yml | 3 ++- src/doc/rustc-dev-guide/.github/workflows/date-check.yml | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.github/workflows/ci.yml b/src/doc/rustc-dev-guide/.github/workflows/ci.yml index c3307bb74d0ff..a2b9cc30d7050 100644 --- a/src/doc/rustc-dev-guide/.github/workflows/ci.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/.github/workflows/date-check.yml b/src/doc/rustc-dev-guide/.github/workflows/date-check.yml index 411117235850a..c787da07122d2 100644 --- a/src/doc/rustc-dev-guide/.github/workflows/date-check.yml +++ b/src/doc/rustc-dev-guide/.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 651110a824ccd3472f66e121926e542c9b0cd41e Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 13 Mar 2021 06:11:30 +0900 Subject: [PATCH 1473/2516] Replace some Travis-related things completely --- src/doc/rustc-dev-guide/README.md | 2 +- src/doc/rustc-dev-guide/ci/linkcheck.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 4595643640db2..99502bcc66f70 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index 8848235480429..f939a7bd87eac 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 fc3832f3ff2556ea5b667614b5756bd7d22197c9 Mon Sep 17 00:00:00 2001 From: JohnTitor Date: Fri, 26 Mar 2021 09:58:24 +0900 Subject: [PATCH 1474/2516] Remove the possible unnecessary flag --- src/doc/rustc-dev-guide/ci/linkcheck.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/linkcheck.sh b/src/doc/rustc-dev-guide/ci/linkcheck.sh index f939a7bd87eac..5d49d133726b4 100755 --- a/src/doc/rustc-dev-guide/ci/linkcheck.sh +++ b/src/doc/rustc-dev-guide/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 a8c17aeeca0d1bba31fefbe2e6f1899e22bc797f Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 27 Apr 2021 12:35:37 -0700 Subject: [PATCH 1475/2516] Suggest using `git range-diff` (#1092) I have found it to be very helpful when rebasing. --- src/doc/rustc-dev-guide/src/git.md | 60 ++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index e533426cfca66..e1b0e02926dc4 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 2822483dd5f3445b82dd40e8e7c395ed4d8e53ec Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Thu, 29 Apr 2021 16:40:25 -0400 Subject: [PATCH 1476/2516] Link to Zulip search for finding the most recent check-in (#1118) --- src/doc/rustc-dev-guide/ci/check-in.sh | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/check-in.sh b/src/doc/rustc-dev-guide/ci/check-in.sh index 323b75d67b740..4477789c764ae 100755 --- a/src/doc/rustc-dev-guide/ci/check-in.sh +++ b/src/doc/rustc-dev-guide/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 861e27723dfd05b4a0e7eb87ad90f3aee101b878 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 5 May 2021 13:53:42 +0200 Subject: [PATCH 1477/2516] add 'waiting-for-review' incantation to main contrib page (#1124) --- src/doc/rustc-dev-guide/src/contributing.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index abe1bb8390b98..02ae1159c647a 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 ec88d1f4d2b913d013930f22c217ccdfbe1b8073 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 1478/2516] Unified CPU Requirements (#1126) --- src/doc/rustc-dev-guide/src/building/prerequisites.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index f7f47d40c58ab..be5d96ad9b677 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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 0dc69c529e4b235cdde401275356445f0d89819d Mon Sep 17 00:00:00 2001 From: Smittyvb Date: Thu, 13 May 2021 14:51:43 -0400 Subject: [PATCH 1479/2516] Document -Zunpretty=thir-tree (#1128) * document -Zunpretty=thir-tree * Update position/wording --- src/doc/rustc-dev-guide/src/thir.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/thir.md b/src/doc/rustc-dev-guide/src/thir.md index b023eb2e2a1cb..0a0218c6bcf3a 100644 --- a/src/doc/rustc-dev-guide/src/thir.md +++ b/src/doc/rustc-dev-guide/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 86fbfc6731e5ffa979922ea80c6808ea8d4071ba Mon Sep 17 00:00:00 2001 From: Rich Kadel Date: Thu, 13 May 2021 19:19:43 -0700 Subject: [PATCH 1480/2516] Update coverage docs (#1122) --- .../src/llvm-coverage-instrumentation.md | 142 +++++++++--------- 1 file changed, 72 insertions(+), 70 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 8a044849f58d1..728805387a45c 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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 2e2bc4b3217c06902774fc771f80dd66c62ae4d0 Mon Sep 17 00:00:00 2001 From: Justus K Date: Tue, 18 May 2021 19:10:39 +0200 Subject: [PATCH 1481/2516] Remove `--stage 1` argument from `doc` invocations (#1125) --- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 2 +- src/doc/rustc-dev-guide/src/rustdoc.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index b2dc2f7fd1e63..7ae68cc21c8f0 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 88177ccba81ba..2123d2b748d0c 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 4727b9b396a8f3a4aecce2edd89405806d7bbb6d Mon Sep 17 00:00:00 2001 From: Caleb Cartwright Date: Thu, 20 May 2021 08:02:20 -0500 Subject: [PATCH 1482/2516] 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/doc/rustc-dev-guide/src/contributing.md | 30 ++++++++++----------- src/doc/rustc-dev-guide/src/git.md | 5 ++-- 2 files changed, 17 insertions(+), 18 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 02ae1159c647a..c07987f30cce4 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index e1b0e02926dc4..e10f1d7050b1c 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 8ec3f77df939fe32ba693d4f3526544e7572759c Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 25 May 2021 17:05:34 -0700 Subject: [PATCH 1483/2516] Describe the difference of rustc_lint vs rustc_lint_defs. --- src/doc/rustc-dev-guide/src/diagnostics.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index f4e71bbdc4cd1..38683f98db7d5 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 2356c878f9fd1e6476fbd21a0e04f4572a65483c Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 12 May 2021 17:00:39 +0200 Subject: [PATCH 1484/2516] not all tools require waiting for a nightly release before they can be fixed --- src/doc/rustc-dev-guide/src/contributing.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index c07987f30cce4..20f76176b12c9 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 8fc58247071aaf207a948d2d82f02befedd24d67 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 26 May 2021 12:22:20 +0200 Subject: [PATCH 1485/2516] improve section introduction --- src/doc/rustc-dev-guide/src/contributing.md | 23 +++++++++------------ 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 20f76176b12c9..cf049015d960e 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 13b8e1449f74d465a9f81896938fcf4f8f9532b9 Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Fri, 28 May 2021 17:23:27 +0200 Subject: [PATCH 1486/2516] Add more information about no_hash query modifier. (#1133) --- .../incremental-compilation-in-detail.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index f0c6dcacd6139..f81e02d28fa79 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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 07b4513dd658b3d4ab653fd6c957a55c678bd42f Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sat, 29 May 2021 21:21:49 +0200 Subject: [PATCH 1487/2516] explain Miri engine vs Miri-the-tool --- src/doc/rustc-dev-guide/src/miri.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index fd091d565b6e4..18cd6ed3923a6 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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 85e560d7ff9a517389e4577eef765cf525a5386f Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 4 Jun 2021 16:08:56 +0900 Subject: [PATCH 1488/2516] Fix some links (#1137) * Fix some links * Address review comment --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 2 +- src/doc/rustc-dev-guide/src/compiler-team.md | 4 ++-- src/doc/rustc-dev-guide/src/identifiers.md | 2 +- src/doc/rustc-dev-guide/src/query.md | 4 ++-- src/doc/rustc-dev-guide/src/thir.md | 6 +++--- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index 0caed3fafbb14..27529314c5657 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index 8cfcc5bb66707..aac2634843151 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/identifiers.md b/src/doc/rustc-dev-guide/src/identifiers.md index 37e6a1c9299d5..50d0c76e2f7bd 100644 --- a/src/doc/rustc-dev-guide/src/identifiers.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 294d61fb3d79c..aa3a8132839d4 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/thir.md b/src/doc/rustc-dev-guide/src/thir.md index 0a0218c6bcf3a..a1d38990792a8 100644 --- a/src/doc/rustc-dev-guide/src/thir.md +++ b/src/doc/rustc-dev-guide/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 00a8451b3c1f8e2921ec6064e83648c5bbcaaa5e Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Wed, 20 Jan 2021 08:17:29 -0800 Subject: [PATCH 1489/2516] Add a section on keeping things up to date in the git section --- .../rustc-dev-guide/src/about-this-guide.md | 4 +- src/doc/rustc-dev-guide/src/contributing.md | 3 +- src/doc/rustc-dev-guide/src/git.md | 47 +++++++++++++++++-- 3 files changed, 47 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index d12f5a7a34a23..0ba753a6259dd 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index cf049015d960e..d8f7a79a1df01 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index e10f1d7050b1c..fb64b3bcab428 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 fcf32f4aa92e2c5afc78dd4c0b97aba476339c3e Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Wed, 9 Jun 2021 08:23:36 -0700 Subject: [PATCH 1490/2516] move 7/8 to prose --- src/doc/rustc-dev-guide/src/git.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index fb64b3bcab428..361b65a81a37c 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 3b0f8f658e34955e30dc5b14999fd26188aade17 Mon Sep 17 00:00:00 2001 From: Jade Date: Sat, 12 Jun 2021 09:17:06 -0700 Subject: [PATCH 1491/2516] Add suggested settings note for coc (#1144) --- src/doc/rustc-dev-guide/src/building/suggested.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index f27793140d380..bb6badcd6e204 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 0ee047e931668b934537155c78663ddbc08e222f Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 14 Jun 2021 15:35:38 -0300 Subject: [PATCH 1492/2516] 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/doc/rustc-dev-guide/src/overview.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 1aa79e791466a..6c756e18ff58b 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 e6951546189821d47abac7b7a178c3b8a4e0d0cf Mon Sep 17 00:00:00 2001 From: Jade Date: Mon, 14 Jun 2021 13:57:10 -0700 Subject: [PATCH 1493/2516] Change the feature used as an example of stabilizing lib features (#1143) --- src/doc/rustc-dev-guide/src/stability.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index cfb4efd891fa8..d3221217ad473 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 ba3c0b898e6f067149dafcc2d5bb54b202d2000c Mon Sep 17 00:00:00 2001 From: Oli Scherer Date: Tue, 15 Jun 2021 10:04:54 +0200 Subject: [PATCH 1494/2516] 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/doc/rustc-dev-guide/src/stability.md | 34 +++++++++++++++--------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index d3221217ad473..0f1aec17ee9fd 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 1cb31172c1102736012183601e94a01e6e197f4c Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 18 Jun 2021 05:25:28 +0900 Subject: [PATCH 1495/2516] Document how to run unit tests (#1141) --- src/doc/rustc-dev-guide/src/tests/running.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 874ef82746114..34a44f9c24c13 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 e5ce66c9f0b005f39748c17be2afdfd2dec2718b Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 22 Jun 2021 04:50:12 +0900 Subject: [PATCH 1496/2516] Update "Inference variables" section (#1145) --- src/doc/rustc-dev-guide/src/type-inference.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 71c2b08b19070..4be9211eeed4c 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 d5334e56c06e8a8208a897e3673b756cfdfe86b3 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 1497/2516] Correct the wrong serial number (#1147) --- .../rustc-dev-guide/src/about-this-guide.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 0ba753a6259dd..3f32659b78ae0 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 6e3cd44c2fdd9f5c7bc7f31d16493d9112468f69 Mon Sep 17 00:00:00 2001 From: Smittyvb Date: Thu, 24 Jun 2021 00:57:37 -0400 Subject: [PATCH 1498/2516] Generate glossary table correctly (#1146) Co-authored-by: Yuki Okushi --- .../rustc-dev-guide/src/appendix/glossary.md | 179 +++++++++--------- 1 file changed, 90 insertions(+), 89 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index eae5758f43e2c..8e5d5b3947386 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/img/llvm-cov-show-01.png b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md new file mode 100644 index 0000000000000..31d4e0d4330c5 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profile-guided-optimization.md b/src/doc/rustc-dev-guide/src/profile-guided-optimization.md index 03198fb1aa7bb..3597ee26896e6 100644 --- a/src/doc/rustc-dev-guide/src/profile-guided-optimization.md +++ b/src/doc/rustc-dev-guide/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 2e4650a6dd862b67681c863d921c943e626dcdc2 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 7 Dec 2020 11:56:25 -0800 Subject: [PATCH 1375/2516] 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/doc/rustc-dev-guide/src/identifiers.md | 49 +++++++++++++++++++++- 1 file changed, 47 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/identifiers.md b/src/doc/rustc-dev-guide/src/identifiers.md index f485132c64027..3923c9332eb2a 100644 --- a/src/doc/rustc-dev-guide/src/identifiers.md +++ b/src/doc/rustc-dev-guide/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 7cd87eb4cdc35b8fce13659fd58ba2c336422c11 Mon Sep 17 00:00:00 2001 From: Nixon Enraght-Moony Date: Thu, 10 Dec 2020 19:46:35 +0000 Subject: [PATCH 1376/2516] All links to rustdoc-internals.md --- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index 1f7f100459612..895263b537f36 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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 74887a057bdb9431b9330e84f1c93cc9243dda05 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 12 Dec 2020 05:57:33 +0900 Subject: [PATCH 1377/2516] 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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 31d4e0d4330c5..6550fb66c605e 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profile-guided-optimization.md b/src/doc/rustc-dev-guide/src/profile-guided-optimization.md index 3597ee26896e6..016397e20d3a7 100644 --- a/src/doc/rustc-dev-guide/src/profile-guided-optimization.md +++ b/src/doc/rustc-dev-guide/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 39df3d6ef2dfde1845403c24fa064d5270e54d18 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 13 Dec 2020 00:06:30 +0900 Subject: [PATCH 1378/2516] Document `error-pattern` header (#989) * Document `error-pattern` header * Address some reviews --- src/doc/rustc-dev-guide/src/tests/adding.md | 33 +++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index acdc2fd251cc0..9c0da6663ac56 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 603f6bd62b19a26289333f5699dcec205f16a5bd 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 1379/2516] [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/doc/rustc-dev-guide/src/appendix/compiler-lecture.md b/src/doc/rustc-dev-guide/src/appendix/compiler-lecture.md index bbeb52aa3a018..dabd2f0870355 100644 --- a/src/doc/rustc-dev-guide/src/appendix/compiler-lecture.md +++ b/src/doc/rustc-dev-guide/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 f53399f06f3db78daac6738869035e087c99bb64 Mon Sep 17 00:00:00 2001 From: Wesley Wiser Date: Mon, 28 Dec 2020 14:05:06 -0500 Subject: [PATCH 1380/2516] 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 --- .../rustc-dev-guide/src/appendix/glossary.md | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 8ecd4f6158b2b..eae5758f43e2c 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 1e2c7215038a710e720f4cbcae84385fd01332d3 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 1381/2516] rustc invocation standarized (#992) * rustc invocation standarized * Addressed comments * Addressed comments * Addressed comments * Updated command output --- .../rustc-dev-guide/src/backend/debugging.md | 22 +++++----- src/doc/rustc-dev-guide/src/closure.md | 6 +-- .../rustc-dev-guide/src/compiler-debugging.md | 40 ++++++++++--------- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- src/doc/rustc-dev-guide/src/hir-debugging.md | 2 +- src/doc/rustc-dev-guide/src/hir.md | 4 +- .../src/llvm-coverage-instrumentation.md | 6 +-- src/doc/rustc-dev-guide/src/mir/dataflow.md | 4 +- src/doc/rustc-dev-guide/src/mir/debugging.md | 22 +++++----- .../src/notification-groups/llvm.md | 4 +- src/doc/rustc-dev-guide/src/overview.md | 10 ++--- .../src/profile-guided-optimization.md | 4 +- src/doc/rustc-dev-guide/src/profiling.md | 32 +++++++-------- .../src/profiling/with_perf.md | 2 +- src/doc/rustc-dev-guide/src/sanitizers.md | 4 +- src/doc/rustc-dev-guide/src/stability.md | 8 ++-- src/doc/rustc-dev-guide/src/tests/adding.md | 2 +- 17 files changed, 89 insertions(+), 85 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/debugging.md b/src/doc/rustc-dev-guide/src/backend/debugging.md index f8ea4f5ed0eb6..7577a0e13dd02 100644 --- a/src/doc/rustc-dev-guide/src/backend/debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index 3b535040e8e43..3330bf1b4532c 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 4b241d8ea691d..e5b93a66f3166 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index fce79d725b7cc..e3a60447b4089 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir-debugging.md b/src/doc/rustc-dev-guide/src/hir-debugging.md index bb7f541fd690f..519ff26677e6c 100644 --- a/src/doc/rustc-dev-guide/src/hir-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index a88ba90666561..014136bde3449 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 6550fb66c605e..1cc6a2717f18e 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index b5cbd46868a78..e3413c5e941a6 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/debugging.md b/src/doc/rustc-dev-guide/src/mir/debugging.md index 3a47a575d59ad..c6734f8aaae65 100644 --- a/src/doc/rustc-dev-guide/src/mir/debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/notification-groups/llvm.md b/src/doc/rustc-dev-guide/src/notification-groups/llvm.md index f1f2097e5f4b1..69edd8b54448e 100644 --- a/src/doc/rustc-dev-guide/src/notification-groups/llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 82f2289e47486..8f1a55d10a9d5 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profile-guided-optimization.md b/src/doc/rustc-dev-guide/src/profile-guided-optimization.md index 016397e20d3a7..09587e6bf1004 100644 --- a/src/doc/rustc-dev-guide/src/profile-guided-optimization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index e8139dd2507e4..a1f1a4b77a867 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 5945f0b027be9..b383ec542b760 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/sanitizers.md b/src/doc/rustc-dev-guide/src/sanitizers.md index 5e1f396f51fa3..4a43698caf1f5 100644 --- a/src/doc/rustc-dev-guide/src/sanitizers.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 1cbbcb8493069..c9e7056d690e9 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 9c0da6663ac56..65f0896e89f22 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 4b5378821671081b59b1eb78f95e3589dd4f756c Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 29 Dec 2020 15:08:55 -0500 Subject: [PATCH 1382/2516] Fix broken link in the contributing guide (#996) --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index fb65a8eae0400..bc846f9c7c83a 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 1189701516fdeb9137a816badb75c5616a220197 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 30 Dec 2020 16:08:00 -0800 Subject: [PATCH 1383/2516] 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 --- .../rustc-dev-guide/src/compiler-debugging.md | 92 +++++++++++++------ 1 file changed, 66 insertions(+), 26 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index e5b93a66f3166..0510e6bcad9ef 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 bcee60a6e30edca169e95a7edf79e98335a3e11f Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 31 Dec 2020 09:13:49 +0900 Subject: [PATCH 1384/2516] Fix broken link for `BoundRegion` (#998) --- src/doc/rustc-dev-guide/src/early-late-bound.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/early-late-bound.md b/src/doc/rustc-dev-guide/src/early-late-bound.md index a703cbab5dd63..973306b86ae94 100644 --- a/src/doc/rustc-dev-guide/src/early-late-bound.md +++ b/src/doc/rustc-dev-guide/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 287434551a51cb6694fdce51c0bc0d29e21545e1 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Fri, 1 Jan 2021 15:59:23 -0500 Subject: [PATCH 1385/2516] Clarify that `check` uses a different stage than `build` (#999) --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 1d420a978df6b..3e5cabbe86fc7 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 bf4e7b347dc273080e62daeef2af8448c69c04e2 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 1386/2516] Fix typo (reflex -> reflect) --- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index a02b854af20b7..40342a7037590 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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 95292a60661405008294f0d84a0625b97deb67ee Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 3 Jan 2021 16:24:53 -0800 Subject: [PATCH 1387/2516] 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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index 2d4214ef36938..8f38853c422a8 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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 ed1ea46be85623eb9cfa1b669be8f611f7717e4a Mon Sep 17 00:00:00 2001 From: Sebastian Widua Date: Mon, 4 Jan 2021 11:36:03 +0100 Subject: [PATCH 1388/2516] Fix some typos --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 2 +- src/doc/rustc-dev-guide/src/tests/intro.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 0510e6bcad9ef..b1addb2495fdf 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 3be9219f61483..51c0e2d6ee91f 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 ec42a83b54c737631c7b42a618a296ef8fb7376a Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Mon, 4 Jan 2021 13:55:24 +0100 Subject: [PATCH 1389/2516] Add link to rust-analyzer docs on getting started page --- src/doc/rustc-dev-guide/src/getting-started.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index da444cdbb0535..8b2fc48f8050b 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 188bf64219bf69328e14071d7e4134389d53408a Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Mon, 4 Jan 2021 07:41:42 -0800 Subject: [PATCH 1390/2516] Update mdbook --- src/doc/rustc-dev-guide/.travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index f503eeefa028b..1e5d86993dc1b 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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 34379a14ad48b6f0b3ae658d275a6accc8993542 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 5 Jan 2021 10:03:54 +0900 Subject: [PATCH 1391/2516] Fix "Potential incomplete link" error on compiler-debugging.md --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index b1addb2495fdf..918761971caf7 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 3a3e83e9338af34df102487f2d40562d9c703385 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 4 Jan 2021 19:28:18 -0800 Subject: [PATCH 1392/2516] Remove old sentence that should have been removed It was mistakenly not removed in #997. --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 918761971caf7..df2d011de20e3 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 24457793eee85752c29f60c8f53f556be9d8c785 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Mon, 4 Jan 2021 16:47:55 +0100 Subject: [PATCH 1393/2516] Make instructions for configuring compiler for debug more explicit --- .../rustc-dev-guide/src/compiler-debugging.md | 30 ++++++++++++------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index df2d011de20e3..a9856349ce589 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 af659a6a91836a2670200492a73f192d915eaa60 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Mon, 4 Jan 2021 17:25:39 +0100 Subject: [PATCH 1394/2516] Update src/compiler-debugging.md Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index a9856349ce589..13cb3cf74f3f1 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 78fdaddcad1170843ac80466c5b6e1477eeccfc9 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Tue, 5 Jan 2021 09:54:03 +0100 Subject: [PATCH 1395/2516] Remove backticks and comment about possible bug --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 13cb3cf74f3f1..2fb2e603f14d2 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 ccac27e3878438446e5bddfc671c95f438484200 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Tue, 5 Jan 2021 09:55:39 +0100 Subject: [PATCH 1396/2516] Break up long line --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 2fb2e603f14d2..a04ef0ea936d5 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 012d6da4893f9d331d58b14857afa5fc673deeed Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 9 Jan 2021 17:18:57 -0800 Subject: [PATCH 1397/2516] Fix typo (#1016) "currenty"! --- src/doc/rustc-dev-guide/src/identifiers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/identifiers.md b/src/doc/rustc-dev-guide/src/identifiers.md index 3923c9332eb2a..d04509b683f2e 100644 --- a/src/doc/rustc-dev-guide/src/identifiers.md +++ b/src/doc/rustc-dev-guide/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 84c3c96d59eeeb1ceeccc31fdc36f8524b511b0d Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 9 Jan 2021 17:10:18 -0800 Subject: [PATCH 1398/2516] Point to `HirId` instead of `NodeId` --- src/doc/rustc-dev-guide/src/identifiers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/identifiers.md b/src/doc/rustc-dev-guide/src/identifiers.md index d04509b683f2e..37e6a1c9299d5 100644 --- a/src/doc/rustc-dev-guide/src/identifiers.md +++ b/src/doc/rustc-dev-guide/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 5e3512a4c6b9085deb9dfb3cb293ded766765dea Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 10 Jan 2021 13:19:39 -0800 Subject: [PATCH 1399/2516] Update 'Workspace structure' section (#1017) * Update description of `src/` * Note that `library/` also contains the Rust runtime --- src/doc/rustc-dev-guide/src/compiler-src.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index b26ede5799bc9..bcf169a133ff3 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 6d05039413afaef0350f63ceb3c0de74ca4fe341 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 1400/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 1 - .../rustc-dev-guide/src/about-this-guide.md | 25 ++++++++++++++--- .../src/backend/backend-agnostic.md | 5 ++-- .../region_inference/member_constraints.md | 5 ++-- src/doc/rustc-dev-guide/src/contributing.md | 27 +++++++++++++++---- .../src/debugging-support-in-rustc.md | 2 -- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- .../src/diagnostics/lintstore.md | 8 +++--- src/doc/rustc-dev-guide/src/git.md | 8 +++--- .../src/llvm-coverage-instrumentation.md | 2 +- src/doc/rustc-dev-guide/src/miri.md | 2 +- .../src/opaque-types-type-alias-impl-trait.md | 2 +- src/doc/rustc-dev-guide/src/overview.md | 12 --------- src/doc/rustc-dev-guide/src/parallel-rustc.md | 7 ++--- src/doc/rustc-dev-guide/src/profiling.md | 2 +- .../incremental-compilation-in-detail.md | 2 +- .../rustc-dev-guide/src/queries/profiling.md | 10 +++---- .../query-evaluation-model-in-detail.md | 10 +++---- src/doc/rustc-dev-guide/src/query.md | 2 +- src/doc/rustc-dev-guide/src/salsa.md | 6 +++-- src/doc/rustc-dev-guide/src/tests/intro.md | 2 +- src/doc/rustc-dev-guide/src/the-parser.md | 4 +-- src/doc/rustc-dev-guide/src/traits/chalk.md | 6 ++--- .../src/traits/lowering-module.md | 3 --- .../rustc-dev-guide/src/traits/resolution.md | 2 +- 25 files changed, 90 insertions(+), 67 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/traits/lowering-module.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 9a695c94d6da6..392b3814ea347 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 77dbf26991f3c..740a8c7bc0df3 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/backend-agnostic.md b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md index e1eeb9a7fb08f..e02bbfe5241a1 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index 0435ff8c85051..4aa63a13c4044 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index bc846f9c7c83a..cc1605d1acffc 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/debugging-support-in-rustc.md b/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md index 912ceffae2b5c..5422e18dcb36e 100644 --- a/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index e3a60447b4089..c88074748b64a 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index 8f0c21ab3d577..e088185a784cf 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index d1e6b8c41ee06..8775b70e67b60 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 1cc6a2717f18e..23117f527dc2b 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index af2a92802a2c2..71a7e6cded943 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md b/src/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md index e78d3c75dec80..e95291fef3bad 100644 --- a/src/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 8f1a55d10a9d5..4fe40c42ffcdc 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index 0405a947a8624..cb36fef6fe5eb 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index a1f1a4b77a867..902281f183623 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index bea9a886f9748..c00ed042e34e8 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index 7e0b686869a09..f124d453a4aad 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index 8f38853c422a8..54f750bbde38d 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 77d3b50e5c253..eb0bbe78ee477 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index 567f1b153a866..36aeb18bf1225 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 51c0e2d6ee91f..04deb427ae943 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index d3e48a17e72f9..915e4bb9a786c 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk.md b/src/doc/rustc-dev-guide/src/traits/chalk.md index 659f6963772d0..540077cf06c80 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-module.md b/src/doc/rustc-dev-guide/src/traits/lowering-module.md deleted file mode 100644 index 8795cb79c6f9d..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md index 236ca966d4bbd..3041b85d89be4 100644 --- a/src/doc/rustc-dev-guide/src/traits/resolution.md +++ b/src/doc/rustc-dev-guide/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 1ac8ff22d8b9547eaca654dcca8b6ac66dabb195 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 12 Jan 2021 07:55:13 +0900 Subject: [PATCH 1401/2516] Add a note about UI test entry limitation (#1019) --- src/doc/rustc-dev-guide/src/tests/adding.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 65f0896e89f22..774ccc3ef31f2 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 01bc71443cc670b0985bd009c66a06e501f0634d 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 1402/2516] Corrected MIR file path and fixed a typo (#1020) --- src/doc/rustc-dev-guide/README.md | 2 +- src/doc/rustc-dev-guide/src/part-5-intro.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 5448ca9bbc03b..c8507374e2028 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/part-5-intro.md b/src/doc/rustc-dev-guide/src/part-5-intro.md index 82663b5625e54..78e6fa2e9bc32 100644 --- a/src/doc/rustc-dev-guide/src/part-5-intro.md +++ b/src/doc/rustc-dev-guide/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 7aa31baa1d134a2c34c9275bc7ef9e268d042dab Mon Sep 17 00:00:00 2001 From: saki-osive Date: Sat, 16 Jan 2021 17:08:11 +0530 Subject: [PATCH 1403/2516] Fixed a grammatical error in hardawre requirements section --- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 8b2fc48f8050b..a460bff010ad9 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 c37d7ef838bea65e7c8350bb360f0eab36896ccf Mon Sep 17 00:00:00 2001 From: ashosive Date: Sat, 16 Jan 2021 22:26:14 +0530 Subject: [PATCH 1404/2516] improved the readablity of a line --- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index a460bff010ad9..d70c3776ec33a 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 3c2fdf47518549ddb76c6fd0c8d704b19219df7a Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sat, 16 Jan 2021 11:22:56 -0500 Subject: [PATCH 1405/2516] Note that `--check` now allows using any stage --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 3e5cabbe86fc7..e132d6941455f 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 940b3b1b5f24d16c58c40a78117dc9e7e1747c97 Mon Sep 17 00:00:00 2001 From: Martin Geisler Date: Sun, 17 Jan 2021 15:50:04 +0100 Subject: [PATCH 1406/2516] Fix typo (#1027) --- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index 895263b537f36..f739ff82a1f07 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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 10f6bbc9576f494b91f7ad8720904adec5658867 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 19 Jan 2021 14:47:45 -0500 Subject: [PATCH 1407/2516] Link to `feature_err` in stability section (#1022) --- src/doc/rustc-dev-guide/src/implementing_new_features.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 3a65f15e75146..03da8762016dd 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 d38f93b7d2be2ef335f0b87720e8c1a47c7d1931 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 1408/2516] 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 --- src/doc/rustc-dev-guide/.travis.yml | 1 + src/doc/rustc-dev-guide/README.md | 9 +++- src/doc/rustc-dev-guide/book.toml | 4 ++ .../rustc-dev-guide/src/about-this-guide.md | 2 +- .../src/backend/backend-agnostic.md | 2 + .../src/backend/implicit-caller-location.md | 46 ++++++++++--------- .../rustc-dev-guide/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 + .../rustc-dev-guide/src/bug-fix-procedure.md | 3 ++ .../src/building/bootstrapping.md | 2 + .../rustc-dev-guide/src/compiler-debugging.md | 16 ++++--- src/doc/rustc-dev-guide/src/compiler-src.md | 4 +- src/doc/rustc-dev-guide/src/contributing.md | 12 ++--- .../src/debugging-support-in-rustc.md | 2 + src/doc/rustc-dev-guide/src/diagnostics.md | 2 + .../rustc-dev-guide/src/getting-started.md | 2 + src/doc/rustc-dev-guide/src/git.md | 2 + src/doc/rustc-dev-guide/src/hir.md | 10 ++-- .../src/llvm-coverage-instrumentation.md | 4 +- .../rustc-dev-guide/src/macro-expansion.md | 2 + .../rustc-dev-guide/src/mir/construction.md | 2 + src/doc/rustc-dev-guide/src/mir/dataflow.md | 2 + src/doc/rustc-dev-guide/src/mir/index.md | 4 +- src/doc/rustc-dev-guide/src/miri.md | 2 + .../rustc-dev-guide/src/name-resolution.md | 2 + src/doc/rustc-dev-guide/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 + .../rustc-dev-guide/src/queries/profiling.md | 3 ++ .../query-evaluation-model-in-detail.md | 4 +- .../rustc-dev-guide/src/rustdoc-internals.md | 2 + src/doc/rustc-dev-guide/src/salsa.md | 2 + src/doc/rustc-dev-guide/src/stability.md | 2 + .../src/stabilization_guide.md | 7 +-- .../src/test-implementation.md | 16 +++++-- src/doc/rustc-dev-guide/src/tests/adding.md | 2 + src/doc/rustc-dev-guide/src/tests/intro.md | 2 + src/doc/rustc-dev-guide/src/tests/running.md | 2 + .../src/traits/goals-and-clauses.md | 4 +- .../src/traits/lowering-to-logic.md | 2 + .../rustc-dev-guide/src/traits/resolution.md | 2 + src/doc/rustc-dev-guide/src/ty.md | 4 +- src/doc/rustc-dev-guide/src/type-inference.md | 2 + src/doc/rustc-dev-guide/src/variance.md | 2 + src/doc/rustc-dev-guide/src/walkthrough.md | 2 + 53 files changed, 177 insertions(+), 76 deletions(-) diff --git a/src/doc/rustc-dev-guide/.travis.yml b/src/doc/rustc-dev-guide/.travis.yml index 1e5d86993dc1b..1d67472583c58 100644 --- a/src/doc/rustc-dev-guide/.travis.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index c8507374e2028..4595643640db2 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index af9cd167fdcd5..bad4fe1aa5f97 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 740a8c7bc0df3..d12f5a7a34a23 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/backend-agnostic.md b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md index e02bbfe5241a1..52532c2582197 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/implicit-caller-location.md b/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md index a621b57b110fe..02eea5bab6415 100644 --- a/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index e678b4f76c0c0..0457c18412ba0 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/updating-llvm.md b/src/doc/rustc-dev-guide/src/backend/updating-llvm.md index 015514bab50a4..df91c8d011c63 100644 --- a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index 2c7c73038de10..e38b923cf372f 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index d8cfab00c28b7..e14bc4157996a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index 1389628c89fb8..f0a7f73535afa 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index 9d6b229ef3b2c..c65b8ce5a54ac 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index 4aa63a13c4044..fd65acf1a0039 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md index 169f1b486c9ff..20775038be44a 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/bug-fix-procedure.md b/src/doc/rustc-dev-guide/src/bug-fix-procedure.md index 69732b6275f79..66b200f9e9618 100644 --- a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index e132d6941455f..9da24e4c6fbcd 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index a04ef0ea936d5..ecb9e30c22d95 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index bcf169a133ff3..5965fd3745f49 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index cc1605d1acffc..83d5e95cbe175 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/debugging-support-in-rustc.md b/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md index 5422e18dcb36e..5590311483a5d 100644 --- a/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index c88074748b64a..f59844d4c1545 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index d70c3776ec33a..0fc5cd8e8687b 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 8775b70e67b60..611c47124ca9c 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 014136bde3449..51e18973b8cd7 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 23117f527dc2b..88831f69d8dff 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 40342a7037590..352d826d337c4 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/construction.md b/src/doc/rustc-dev-guide/src/mir/construction.md index 010305556cf52..d2c5a6f3442c1 100644 --- a/src/doc/rustc-dev-guide/src/mir/construction.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index e3413c5e941a6..9958f19b999f2 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index 55a4a434991b6..5d137697511a0 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index 71a7e6cded943..d0766a07b9108 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 3785e3aa78256..2eb76384c0f3f 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 4fe40c42ffcdc..5a63d6066b8dc 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/panic-implementation.md b/src/doc/rustc-dev-guide/src/panic-implementation.md index 7c10ae215b8d3..66e61548efafe 100644 --- a/src/doc/rustc-dev-guide/src/panic-implementation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profile-guided-optimization.md b/src/doc/rustc-dev-guide/src/profile-guided-optimization.md index 09587e6bf1004..145bb053c2c67 100644 --- a/src/doc/rustc-dev-guide/src/profile-guided-optimization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index c00ed042e34e8..f0c6dcacd6139 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/incremental-compilation.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md index 5ff189f96ef76..abef144d7d221 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index f124d453a4aad..8cd4c07d8cde7 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index 54f750bbde38d..51501d3d5e0a3 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index f739ff82a1f07..288d762b833a4 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index 36aeb18bf1225..38db066c5d362 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index c9e7056d690e9..69e434c071870 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 2cdb0037bdcb7..f4f58c3923585 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/test-implementation.md b/src/doc/rustc-dev-guide/src/test-implementation.md index 230e2fe364276..1a9283b5976da 100644 --- a/src/doc/rustc-dev-guide/src/test-implementation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 774ccc3ef31f2..868bad2d7ada7 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 04deb427ae943..cab06df554dfb 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 4fe61f30a931e..842a73c072691 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md index 9aaab96faa7ad..4315b3e0f3524 100644 --- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/lowering-to-logic.md b/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md index cc8b3bf800cb9..1248d434610b9 100644 --- a/src/doc/rustc-dev-guide/src/traits/lowering-to-logic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md index 3041b85d89be4..863631320865d 100644 --- a/src/doc/rustc-dev-guide/src/traits/resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 49f6405fa791e..9ee2ccfe2d0ac 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 9c548364d4c5d..9d23b627829db 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md index af23330e8a5df..c03de7a20ddbf 100644 --- a/src/doc/rustc-dev-guide/src/variance.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 8a41b3dd89b19..b0d040942e700 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 1e695f2e0c1e438d66928aa5fcb1dac611d34ab0 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 20 Jan 2021 10:46:13 -0500 Subject: [PATCH 1409/2516] 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 +++++ .../rustc-dev-guide/src/building/suggested.md | 34 ------------------- 2 files changed, 9 insertions(+), 34 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md b/src/doc/rustc-dev-guide/src/backend/updating-llvm.md index df91c8d011c63..77b2fdea7bf75 100644 --- a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 58996e639a509..6e0f830c65a8b 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 e61acde6b56d5458d9472a3ffdfaac004db2a797 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 20 Jan 2021 17:42:24 -0800 Subject: [PATCH 1410/2516] Add missing period --- src/doc/rustc-dev-guide/src/backend/updating-llvm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md b/src/doc/rustc-dev-guide/src/backend/updating-llvm.md index 77b2fdea7bf75..896a0f49406a9 100644 --- a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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 2a40488f9438a222dd875268ea536b5d084d1b4e Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Fri, 22 Jan 2021 05:49:52 -0500 Subject: [PATCH 1411/2516] Add link to promotion.md (#1033) * Add link to promotion.md * Improve link text Co-authored-by: Camelid Co-authored-by: Camelid --- src/doc/rustc-dev-guide/src/mir/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index 5d137697511a0..306d2abfd270d 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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 04c76bad2820cc0b1741d385c3987afde8c7587a Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sun, 24 Jan 2021 11:15:39 +0100 Subject: [PATCH 1412/2516] Update links to `librustc_llvm` and `rustllvm` --- src/doc/rustc-dev-guide/src/backend/updating-llvm.md | 12 +++++++----- src/doc/rustc-dev-guide/src/compiler-src.md | 11 +++++------ 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md b/src/doc/rustc-dev-guide/src/backend/updating-llvm.md index 896a0f49406a9..a769b428dfca4 100644 --- a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 5965fd3745f49..9880f9153f99e 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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 76c8acfe5c3741f02cebe6188814e7c28296c94d Mon Sep 17 00:00:00 2001 From: Henry Boisdequin Date: Sat, 30 Jan 2021 14:07:02 +0530 Subject: [PATCH 1413/2516] put `x.py` in ticks --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 9da24e4c6fbcd..5437a460a32d1 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 efdb545ac72f76605b0209a239451de0c4457d0d Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sat, 30 Jan 2021 03:12:01 -0800 Subject: [PATCH 1414/2516] Update test suite descriptions. (#1042) --- src/doc/rustc-dev-guide/src/tests/intro.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index cab06df554dfb..55be23cd6c0c4 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 9fb6690ae99afc1d7d350953eb378629ab507bc2 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 1 Feb 2021 13:31:00 -0500 Subject: [PATCH 1415/2516] 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. --- .../rustc-dev-guide/ci/check_line_lengths.sh | 1 + .../src/building/bootstrapping.md | 30 ++++++++++ src/doc/rustc-dev-guide/src/stability.md | 55 +++++++------------ .../src/stabilization_guide.md | 5 ++ 4 files changed, 55 insertions(+), 36 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh b/src/doc/rustc-dev-guide/ci/check_line_lengths.sh index 8ecb8a309b64c..31cda5c65e911 100755 --- a/src/doc/rustc-dev-guide/ci/check_line_lengths.sh +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 5437a460a32d1..68c4b1ad0d0c7 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 69e434c071870..cfb4efd891fa8 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index f4f58c3923585..a6203a3c60058 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 bc320e7800f445939aa5c35c2c6bd019e15d1ecc Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 23 Jan 2021 13:38:22 -0800 Subject: [PATCH 1416/2516] 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 ++++ src/doc/rustc-dev-guide/.gitignore | 4 +- .../rustc-dev-guide/ci/date-check/Cargo.lock | 147 +++++++++++ .../rustc-dev-guide/ci/date-check/Cargo.toml | 12 + .../rustc-dev-guide/ci/date-check/src/main.rs | 236 ++++++++++++++++++ 5 files changed, 442 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/.github/workflows/date-check.yml create mode 100644 src/doc/rustc-dev-guide/ci/date-check/Cargo.lock create mode 100644 src/doc/rustc-dev-guide/ci/date-check/Cargo.toml create mode 100644 src/doc/rustc-dev-guide/ci/date-check/src/main.rs diff --git a/src/doc/rustc-dev-guide/.github/workflows/date-check.yml b/src/doc/rustc-dev-guide/.github/workflows/date-check.yml new file mode 100644 index 0000000000000..411117235850a --- /dev/null +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/.gitignore b/src/doc/rustc-dev-guide/.gitignore index b8cb34883f587..2901de5ed8018 100644 --- a/src/doc/rustc-dev-guide/.gitignore +++ b/src/doc/rustc-dev-guide/.gitignore @@ -1,4 +1,6 @@ book -# prevent accidentally changes +# prevent accidental changes book.toml + +ci/date-check/target/ diff --git a/src/doc/rustc-dev-guide/ci/date-check/Cargo.lock b/src/doc/rustc-dev-guide/ci/date-check/Cargo.lock new file mode 100644 index 0000000000000..296a132d43e1d --- /dev/null +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/date-check/Cargo.toml b/src/doc/rustc-dev-guide/ci/date-check/Cargo.toml new file mode 100644 index 0000000000000..95251fb12335d --- /dev/null +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/ci/date-check/src/main.rs b/src/doc/rustc-dev-guide/ci/date-check/src/main.rs new file mode 100644 index 0000000000000..d78b430b5c71e --- /dev/null +++ b/src/doc/rustc-dev-guide/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 1f840fdd6376b6680f47692a5a7c011f9602bf69 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 20 Jan 2021 16:42:10 -0800 Subject: [PATCH 1417/2516] 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/doc/rustc-dev-guide/src/compiler-src.md | 11 ++++++----- src/doc/rustc-dev-guide/src/contributing.md | 6 +++++- src/doc/rustc-dev-guide/src/diagnostics.md | 6 +++--- .../src/diagnostics/lintstore.md | 7 ++++--- src/doc/rustc-dev-guide/src/git.md | 12 ++++++------ .../src/llvm-coverage-instrumentation.md | 19 +++++++++---------- src/doc/rustc-dev-guide/src/miri.md | 13 +++++++------ .../src/opaque-types-type-alias-impl-trait.md | 5 +++-- src/doc/rustc-dev-guide/src/overview.md | 12 ++++++------ src/doc/rustc-dev-guide/src/parallel-rustc.md | 11 ++++++----- src/doc/rustc-dev-guide/src/profiling.md | 8 ++++---- .../rustc-dev-guide/src/queries/profiling.md | 4 ++-- .../query-evaluation-model-in-detail.md | 9 +++++---- src/doc/rustc-dev-guide/src/query.md | 17 ++++++++--------- .../rustc-dev-guide/src/rustdoc-internals.md | 2 +- src/doc/rustc-dev-guide/src/salsa.md | 8 ++++---- src/doc/rustc-dev-guide/src/tests/adding.md | 14 +++++++------- src/doc/rustc-dev-guide/src/tests/intro.md | 14 +++++++------- src/doc/rustc-dev-guide/src/the-parser.md | 4 ++-- src/doc/rustc-dev-guide/src/traits/chalk.md | 13 ++++++------- .../rustc-dev-guide/src/traits/resolution.md | 10 +++++----- src/doc/rustc-dev-guide/src/type-inference.md | 4 ++-- 24 files changed, 118 insertions(+), 112 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md index 52532c2582197..f61bf62b34491 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index fd65acf1a0039..f64e39461f706 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 9880f9153f99e..96e91fd7375dc 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 83d5e95cbe175..fbcd2001a98fc 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index f59844d4c1545..6a447c00dc4f6 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index e088185a784cf..d6fdd1e34a04a 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 611c47124ca9c..69cdba839b40e 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 88831f69d8dff..9a78935e403f9 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index d0766a07b9108..54f96391ae8db 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md b/src/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md index e95291fef3bad..53522114d5ffb 100644 --- a/src/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 5a63d6066b8dc..45ae0ab2ef1fa 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index cb36fef6fe5eb..6f7f6f54baadf 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index 902281f183623..aa8bf27a22c3c 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index 8cd4c07d8cde7..d903eabff60b6 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index 51501d3d5e0a3..eb6659420d575 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index eb0bbe78ee477..b03aaa8b45804 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index 288d762b833a4..7460c012cb00a 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index 38db066c5d362..67d813b28a829 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 868bad2d7ada7..c19271d2c77b1 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 55be23cd6c0c4..6b2f9452f366c 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index 915e4bb9a786c..9c3433884bea2 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk.md b/src/doc/rustc-dev-guide/src/traits/chalk.md index 540077cf06c80..8b2e2030450fa 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md index 863631320865d..f2ffdcc9766e7 100644 --- a/src/doc/rustc-dev-guide/src/traits/resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 9d23b627829db..6496b48ff2164 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 133328369119dbc36f6651d83c8a557c51f47808 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 4 Feb 2021 10:35:34 -0300 Subject: [PATCH 1418/2516] Make check-in.sh output in way that suggest to add only the most relevant info --- src/doc/rustc-dev-guide/ci/check-in.sh | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/check-in.sh b/src/doc/rustc-dev-guide/ci/check-in.sh index ef61b68715d48..323b75d67b740 100755 --- a/src/doc/rustc-dev-guide/ci/check-in.sh +++ b/src/doc/rustc-dev-guide/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 0a37294c5ab274ed9bf195620762f329a6474ff1 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 4 Feb 2021 08:34:52 -0800 Subject: [PATCH 1419/2516] Add chapter on libs and metadata. (#1044) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/backend/libs-and-metadata.md | 192 ++++++++++++++++++ 2 files changed, 193 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 392b3814ea347..02e8e3843f3c5 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/libs-and-metadata.md b/src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md new file mode 100644 index 0000000000000..91d8cb3aab2a8 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 5e123216cdbe9661d85a995915dc002ea3d92e14 Mon Sep 17 00:00:00 2001 From: Yusuke Tanaka Date: Mon, 8 Feb 2021 01:15:54 +0900 Subject: [PATCH 1420/2516] Fix typo in Bug Fix Procedure (#1050) --- src/doc/rustc-dev-guide/src/bug-fix-procedure.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md b/src/doc/rustc-dev-guide/src/bug-fix-procedure.md index 66b200f9e9618..8702f8aa9434a 100644 --- a/src/doc/rustc-dev-guide/src/bug-fix-procedure.md +++ b/src/doc/rustc-dev-guide/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 1f14b9057d5f1a6cdcd2391768c3c20a360414fd Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 7 Feb 2021 19:07:48 -0800 Subject: [PATCH 1421/2516] Fix typo --- src/doc/rustc-dev-guide/src/compiler-debugging.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index ecb9e30c22d95..34f5e760f1d81 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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 4e372e67805e6a3409d45ccc539854e3d15f4f63 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 1422/2516] Add Oxide paper to bibliography --- src/doc/rustc-dev-guide/src/appendix/bibliography.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/bibliography.md b/src/doc/rustc-dev-guide/src/appendix/bibliography.md index b5defaefd25e8..c8b4a23b345d3 100644 --- a/src/doc/rustc-dev-guide/src/appendix/bibliography.md +++ b/src/doc/rustc-dev-guide/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 3fa03ed24cbeb159d3da8a08c81422157b978bce 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 1423/2516] Update running.md --- src/doc/rustc-dev-guide/src/tests/running.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 842a73c072691..874ef82746114 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 d3a988590cbba805164034b93b280b8159763acd 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 1424/2516] Fix typo (#1063) --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 68c4b1ad0d0c7..61537dbf874fb 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 b636598abf690e03a86cd9a2e30c895f1d34cba8 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 20 Feb 2021 10:01:54 +0900 Subject: [PATCH 1425/2516] Point to main branch on llvm-project's links --- src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md | 2 +- src/doc/rustc-dev-guide/src/profile-guided-optimization.md | 2 +- src/doc/rustc-dev-guide/src/sanitizers.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 9a78935e403f9..132de71734dbe 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profile-guided-optimization.md b/src/doc/rustc-dev-guide/src/profile-guided-optimization.md index 145bb053c2c67..bf7615878cad3 100644 --- a/src/doc/rustc-dev-guide/src/profile-guided-optimization.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/sanitizers.md b/src/doc/rustc-dev-guide/src/sanitizers.md index 4a43698caf1f5..ce07140340f2a 100644 --- a/src/doc/rustc-dev-guide/src/sanitizers.md +++ b/src/doc/rustc-dev-guide/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 96ae33e9cedb3ec95d0b785ef662195ac46d8428 Mon Sep 17 00:00:00 2001 From: r00ster Date: Sat, 20 Feb 2021 13:58:22 +0100 Subject: [PATCH 1426/2516] 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/doc/rustc-dev-guide/src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 69cdba839b40e..d23cd3f0dce0b 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 ff9364473c9d18034ea839fbbf2cdbf58087cbad Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 20 Feb 2021 19:24:01 -0800 Subject: [PATCH 1427/2516] 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/doc/rustc-dev-guide/src/diagnostics.md | 2 +- src/doc/rustc-dev-guide/src/git.md | 2 +- src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md | 4 ++-- .../rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md | 4 ++-- src/doc/rustc-dev-guide/src/query.md | 2 +- src/doc/rustc-dev-guide/src/traits/chalk.md | 4 ++-- src/doc/rustc-dev-guide/src/type-inference.md | 2 +- 7 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 6a447c00dc4f6..f4e71bbdc4cd1 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index d23cd3f0dce0b..d906199483630 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 132de71734dbe..8a044849f58d1 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md b/src/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md index 53522114d5ffb..2be072dd2c55c 100644 --- a/src/doc/rustc-dev-guide/src/opaque-types-type-alias-impl-trait.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index b03aaa8b45804..9f56283dbeae6 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk.md b/src/doc/rustc-dev-guide/src/traits/chalk.md index 8b2e2030450fa..24f2d749a5982 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 6496b48ff2164..7674fdf5a4fa7 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 63355d2b72eed349875d8a1e84a70a1a03a04960 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 20 Feb 2021 19:27:24 -0800 Subject: [PATCH 1428/2516] 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/doc/rustc-dev-guide/src/compiler-src.md | 4 -- src/doc/rustc-dev-guide/src/overview.md | 6 +- src/doc/rustc-dev-guide/src/parallel-rustc.md | 6 +- .../rustc-dev-guide/src/rustdoc-internals.md | 60 +++++++++++++++---- src/doc/rustc-dev-guide/src/tests/adding.md | 4 +- 5 files changed, 56 insertions(+), 24 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 96e91fd7375dc..c4f41544176be 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 45ae0ab2ef1fa..c34d01dfd913f 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index 6f7f6f54baadf..c47a46e78891c 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index 7460c012cb00a..f7799f9673630 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index c19271d2c77b1..4653176722be6 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 adb5c2c49e34ca328ebe7250850cf66c79c88370 Mon Sep 17 00:00:00 2001 From: Hirochika Matsumoto Date: Sun, 21 Feb 2021 17:51:34 +0900 Subject: [PATCH 1429/2516] Fix broken links in query.md (#1068) --- src/doc/rustc-dev-guide/src/query.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 9f56283dbeae6..294d61fb3d79c 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 a71819b012c98db21815b9ef32b68b4b52d526dd Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 22 Feb 2021 01:22:23 -0800 Subject: [PATCH 1430/2516] Fix formatting of more date references (#1067) --- .../rustc-dev-guide/src/backend/backend-agnostic.md | 2 +- .../region_inference/member_constraints.md | 4 ++-- src/doc/rustc-dev-guide/src/compiler-src.md | 2 +- src/doc/rustc-dev-guide/src/contributing.md | 11 +++++++++++ src/doc/rustc-dev-guide/src/diagnostics/lintstore.md | 2 +- src/doc/rustc-dev-guide/src/miri.md | 2 +- src/doc/rustc-dev-guide/src/overview.md | 8 ++++---- src/doc/rustc-dev-guide/src/parallel-rustc.md | 4 ++-- src/doc/rustc-dev-guide/src/profiling.md | 6 +++--- src/doc/rustc-dev-guide/src/queries/profiling.md | 2 +- .../src/queries/query-evaluation-model-in-detail.md | 2 +- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 2 +- src/doc/rustc-dev-guide/src/salsa.md | 2 +- src/doc/rustc-dev-guide/src/tests/adding.md | 4 ++-- src/doc/rustc-dev-guide/src/tests/intro.md | 4 ++-- src/doc/rustc-dev-guide/src/the-parser.md | 2 +- src/doc/rustc-dev-guide/src/traits/resolution.md | 2 +- src/doc/rustc-dev-guide/src/type-inference.md | 4 ++-- 18 files changed, 38 insertions(+), 27 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md index f61bf62b34491..3299e2cc79ffb 100644 --- a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index f64e39461f706..9e22aabc956a4 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index c4f41544176be..61af386522ea8 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index fbcd2001a98fc..4a199498603b3 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index d6fdd1e34a04a..6a59cf264745a 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index 54f96391ae8db..fd091d565b6e4 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index c34d01dfd913f..1aa79e791466a 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index c47a46e78891c..8be19e8dcfe5f 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index aa8bf27a22c3c..429376167d5a0 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md index d903eabff60b6..1160ba818861b 100644 --- a/src/doc/rustc-dev-guide/src/queries/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index eb6659420d575..4c2427e3c4eb6 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index f7799f9673630..3e950a0eb85ae 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index 67d813b28a829..bfe7538247831 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 4653176722be6..944b895b52a5b 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 6b2f9452f366c..6419133455829 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/the-parser.md b/src/doc/rustc-dev-guide/src/the-parser.md index 9c3433884bea2..ff43220c14127 100644 --- a/src/doc/rustc-dev-guide/src/the-parser.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md index f2ffdcc9766e7..70b53e9105748 100644 --- a/src/doc/rustc-dev-guide/src/traits/resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md index 7674fdf5a4fa7..71c2b08b19070 100644 --- a/src/doc/rustc-dev-guide/src/type-inference.md +++ b/src/doc/rustc-dev-guide/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 66627ab487ad35cd6a977f71b96686982059e93f Mon Sep 17 00:00:00 2001 From: Daniel Santos Date: Wed, 24 Feb 2021 20:46:27 -0500 Subject: [PATCH 1431/2516] Fixes typo in getting started guide --- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 0fc5cd8e8687b..99511e8ea56e9 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 9f196f1337f01d48ee00996c0c88a838361c4c18 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 27 Jan 2021 17:49:24 -0800 Subject: [PATCH 1432/2516] Update some out-of-date information --- .../rustc-dev-guide/src/appendix/humorust.md | 2 +- .../src/backend/updating-llvm.md | 6 +++--- .../rustc-dev-guide/src/building/new-target.md | 10 ++-------- src/doc/rustc-dev-guide/src/getting-started.md | 18 +++++++++++------- src/doc/rustc-dev-guide/src/traits/chalk.md | 2 +- 5 files changed, 18 insertions(+), 20 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md index 3bbedf5bb2e40..1171161bd763a 100644 --- a/src/doc/rustc-dev-guide/src/appendix/humorust.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/updating-llvm.md b/src/doc/rustc-dev-guide/src/backend/updating-llvm.md index a769b428dfca4..3e08b3f6944a1 100644 --- a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index 4873e66527088..305aa4de702b2 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 99511e8ea56e9..eed8855c78a98 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/chalk.md b/src/doc/rustc-dev-guide/src/traits/chalk.md index 24f2d749a5982..db3c19a386091 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk.md +++ b/src/doc/rustc-dev-guide/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 33d4d6082456220bc15da79eec6aa4e511625bda Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 20 Feb 2021 16:07:36 -0800 Subject: [PATCH 1433/2516] 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/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index 305aa4de702b2..7701fdbac0a4c 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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 a9f1c46aa4c1c80eb0121c4f88a268c16f2def51 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 20 Feb 2021 16:12:08 -0800 Subject: [PATCH 1434/2516] Fix typos --- src/doc/rustc-dev-guide/src/backend/updating-llvm.md | 6 +++--- src/doc/rustc-dev-guide/src/getting-started.md | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md b/src/doc/rustc-dev-guide/src/backend/updating-llvm.md index 3e08b3f6944a1..a9c3b45c41466 100644 --- a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index eed8855c78a98..a1bf0d50d5d1c 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 9b34c5f4ff5da4c929e9bdd7f4861d4a4a06ce45 Mon Sep 17 00:00:00 2001 From: Camelid Date: Fri, 26 Feb 2021 11:57:54 -0800 Subject: [PATCH 1435/2516] Remove some unrelated changes --- src/doc/rustc-dev-guide/src/getting-started.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index a1bf0d50d5d1c..14795e083af56 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 2c22e37c1121038b79e3a3a17d9acee7d5b215ba Mon Sep 17 00:00:00 2001 From: Camelid Date: Fri, 26 Feb 2021 12:00:24 -0800 Subject: [PATCH 1436/2516] Document how to enable CI LLVM without using `x.py setup` --- src/doc/rustc-dev-guide/src/getting-started.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 14795e083af56..18e429e5ea494 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 68a99f977b6e0835754a51b81676077b2a89f6f1 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 28 Feb 2021 16:19:09 +0900 Subject: [PATCH 1437/2516] Fix broken links --- src/doc/rustc-dev-guide/src/appendix/humorust.md | 2 +- src/doc/rustc-dev-guide/src/closure.md | 2 +- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md index 1171161bd763a..a7ba61769929a 100644 --- a/src/doc/rustc-dev-guide/src/appendix/humorust.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index 3330bf1b4532c..93683383ff473 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 4a199498603b3..d0c77edf26bed 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 14e4e04cf4eb99baa1195eb88807312efcd0889d Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 28 Feb 2021 11:21:01 -0800 Subject: [PATCH 1438/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 4 ++-- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 2 +- src/doc/rustc-dev-guide/src/rustdoc.md | 15 ++++++--------- 3 files changed, 9 insertions(+), 12 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 02e8e3843f3c5..056ff050f892f 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index 3e950a0eb85ae..b2dc2f7fd1e63 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index c087689d9b43a..33f2c5f357194 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 babe1a38d33a658ddc1ff76a3bee8822cdc7c44a 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 1439/2516] 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/doc/rustc-dev-guide/src/profiling.md | 68 ++++++++++++++---------- 1 file changed, 41 insertions(+), 27 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index 429376167d5a0..155dda97dea30 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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 7ea9913e403bf0004386e36355f4446ed979aa1e Mon Sep 17 00:00:00 2001 From: Wesley Wiser Date: Mon, 8 Mar 2021 14:42:56 -0500 Subject: [PATCH 1440/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/img/wpa-initial-memory.png | Bin 0 -> 312637 bytes src/doc/rustc-dev-guide/src/img/wpa-stack.png | Bin 0 -> 145576 bytes src/doc/rustc-dev-guide/src/profiling.md | 4 + .../src/profiling/wpa_profiling.md | 108 ++++++++++++++++++ 5 files changed, 113 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/img/wpa-initial-memory.png create mode 100644 src/doc/rustc-dev-guide/src/img/wpa-stack.png create mode 100644 src/doc/rustc-dev-guide/src/profiling/wpa_profiling.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 056ff050f892f..24117886466a4 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/img/wpa-initial-memory.png b/src/doc/rustc-dev-guide/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 602444c5b9472f66d34f76cd55939e8911c0becb 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 1499/2516] Remove requests or suggestions about rebase and fixup contradictory to rust-highfive bot comment (#1111) --- src/doc/rustc-dev-guide/src/contributing.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index d8f7a79a1df01..9df9b6dfc153c 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 6ca1ad3d8a4225d28492c930d4704bf4210b6623 Mon Sep 17 00:00:00 2001 From: Smittyvb Date: Tue, 29 Jun 2021 12:41:13 -0400 Subject: [PATCH 1500/2516] 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/doc/rustc-dev-guide/src/feature-gates.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/feature-gates.md b/src/doc/rustc-dev-guide/src/feature-gates.md index db6c72ff81093..229281f2f0ba0 100644 --- a/src/doc/rustc-dev-guide/src/feature-gates.md +++ b/src/doc/rustc-dev-guide/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 8a175aa2d30103246d498ef1c4275b1fffd14256 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Thu, 1 Jul 2021 04:19:06 -0700 Subject: [PATCH 1501/2516] Links from rustc-dev-guide to std-dev-guide (#1152) --- src/doc/rustc-dev-guide/README.md | 3 +++ src/doc/rustc-dev-guide/src/about-this-guide.md | 2 ++ 2 files changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/README.md b/src/doc/rustc-dev-guide/README.md index 99502bcc66f70..006ea3231bd3b 100644 --- a/src/doc/rustc-dev-guide/README.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 3f32659b78ae0..3fa397ae4082a 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 64b23c7f60ed36730dade2c420ce92d8addbbe34 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Fri, 2 Jul 2021 10:43:12 +0200 Subject: [PATCH 1502/2516] 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/doc/rustc-dev-guide/src/ast-validation.md | 2 +- src/doc/rustc-dev-guide/src/backend/inline-asm.md | 5 +++-- src/doc/rustc-dev-guide/src/crates-io.md | 4 +++- src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md | 3 +-- src/doc/rustc-dev-guide/src/feature-gate-ck.md | 2 +- src/doc/rustc-dev-guide/src/hir-debugging.md | 2 +- src/doc/rustc-dev-guide/src/identifiers.md | 2 +- src/doc/rustc-dev-guide/src/macro-expansion.md | 4 ++-- src/doc/rustc-dev-guide/src/name-resolution.md | 2 +- src/doc/rustc-dev-guide/src/type-checking.md | 2 +- 10 files changed, 15 insertions(+), 13 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/ast-validation.md b/src/doc/rustc-dev-guide/src/ast-validation.md index 64e35bb93cf5a..ff549ca624e85 100644 --- a/src/doc/rustc-dev-guide/src/ast-validation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/inline-asm.md b/src/doc/rustc-dev-guide/src/backend/inline-asm.md index 0cae01ef3957f..f1a64b5ee1d61 100644 --- a/src/doc/rustc-dev-guide/src/backend/inline-asm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/crates-io.md b/src/doc/rustc-dev-guide/src/crates-io.md index 6fbabdc914b04..bc59bfeeda02a 100644 --- a/src/doc/rustc-dev-guide/src/crates-io.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/debugging-support-in-rustc.md b/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md index 5590311483a5d..9d455084d0da0 100644 --- a/src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/feature-gate-ck.md b/src/doc/rustc-dev-guide/src/feature-gate-ck.md index 3b3a07a31a627..c17747a11b757 100644 --- a/src/doc/rustc-dev-guide/src/feature-gate-ck.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/hir-debugging.md b/src/doc/rustc-dev-guide/src/hir-debugging.md index 519ff26677e6c..8788ad4de1ac4 100644 --- a/src/doc/rustc-dev-guide/src/hir-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/identifiers.md b/src/doc/rustc-dev-guide/src/identifiers.md index 50d0c76e2f7bd..18a3efefcd8a1 100644 --- a/src/doc/rustc-dev-guide/src/identifiers.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 7385cefb38449..ce82852832058 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/name-resolution.md b/src/doc/rustc-dev-guide/src/name-resolution.md index 2eb76384c0f3f..1cef7d08fa806 100644 --- a/src/doc/rustc-dev-guide/src/name-resolution.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/type-checking.md b/src/doc/rustc-dev-guide/src/type-checking.md index 797cd9487a887..cd58faf22bf6d 100644 --- a/src/doc/rustc-dev-guide/src/type-checking.md +++ b/src/doc/rustc-dev-guide/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 0a02e666a8c3cd9fcc38ebbe8e2b870e3a8b8297 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Fri, 2 Jul 2021 10:43:34 +0200 Subject: [PATCH 1503/2516] Update around half of the January 2021 date references (#1155) --- src/doc/rustc-dev-guide/src/compiler-src.md | 9 --------- src/doc/rustc-dev-guide/src/diagnostics/lintstore.md | 2 +- src/doc/rustc-dev-guide/src/git.md | 7 ++++--- src/doc/rustc-dev-guide/src/miri.md | 7 +++---- src/doc/rustc-dev-guide/src/parallel-rustc.md | 2 +- src/doc/rustc-dev-guide/src/query.md | 2 +- src/doc/rustc-dev-guide/src/salsa.md | 2 +- 7 files changed, 11 insertions(+), 20 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index 61af386522ea8..b621dde7c202b 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index 6a59cf264745a..b45e605586fe4 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 361b65a81a37c..1c311982cadc5 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index 18cd6ed3923a6..c19ba6401249f 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index 8be19e8dcfe5f..eec8219a5b7fc 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index aa3a8132839d4..20e547b1e35db 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index bfe7538247831..9bf93727a3834 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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 140ae0b62fe47e3c578a4cb269ccd8193ffba6dc Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Thu, 1 Jul 2021 13:56:19 +0200 Subject: [PATCH 1504/2516] Update section of lint store --- .../src/diagnostics/lintstore.md | 61 +++++++++++-------- 1 file changed, 34 insertions(+), 27 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index b45e605586fe4..ed2100eb7045d 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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 3c714106705cb15e9f9bd2178a94276b4d61848c Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Thu, 1 Jul 2021 14:35:24 +0200 Subject: [PATCH 1505/2516] Update information on lints particularly on future-incompatible --- src/doc/rustc-dev-guide/src/diagnostics.md | 60 ++++++++++++++-------- 1 file changed, 38 insertions(+), 22 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 38683f98db7d5..f2e6f0a6708b6 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 8c983de7ede683ffe24f7a20bb4a96bcb244b136 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Thu, 1 Jul 2021 17:05:19 +0200 Subject: [PATCH 1506/2516] Fix line lens --- src/doc/rustc-dev-guide/src/diagnostics/lintstore.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index ed2100eb7045d..d2796c07049d4 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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 a03a4cf0cec76774edf34f47748f87da148f1f01 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Sun, 4 Jul 2021 20:03:29 +0200 Subject: [PATCH 1507/2516] More specifics on what future-incompatible lints are used for --- src/doc/rustc-dev-guide/src/diagnostics.md | 24 +++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index f2e6f0a6708b6..385d7db60fd8c 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 441275222ca21432df958869db527c9352ed6c34 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 5 Jul 2021 02:34:33 -0400 Subject: [PATCH 1508/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/lang-items.md | 67 +++++++++++++++++++++++ 2 files changed, 68 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/lang-items.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 3f14c2642173e..5fa267601241b 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/lang-items.md b/src/doc/rustc-dev-guide/src/lang-items.md new file mode 100644 index 0000000000000..c5774c43ba42c --- /dev/null +++ b/src/doc/rustc-dev-guide/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 8b96cd0b64d6a903b1c9bdf60def334e91f91cc9 Mon Sep 17 00:00:00 2001 From: Yoh Deadfall Date: Mon, 5 Jul 2021 18:18:21 +0300 Subject: [PATCH 1509/2516] Fixed typos in inline code --- src/doc/rustc-dev-guide/src/stability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 0f1aec17ee9fd..7eff3e88bc618 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 bec4406ccf24dc786c12fb2682cb772c171505ee Mon Sep 17 00:00:00 2001 From: Eric Holk Date: Wed, 7 Jul 2021 16:27:47 -0700 Subject: [PATCH 1510/2516] Minor capitalization fix (#1170) --- src/doc/rustc-dev-guide/src/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index b0d040942e700..5841afe4f54a8 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 f4e53bb520ee47e496e3f75b184feca735c96164 Mon Sep 17 00:00:00 2001 From: bjorn3 Date: Sun, 30 May 2021 21:02:22 +0200 Subject: [PATCH 1511/2516] 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/doc/rustc-dev-guide/src/backend/libs-and-metadata.md b/src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md index 91d8cb3aab2a8..d2cf8b6929ca5 100644 --- a/src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md +++ b/src/doc/rustc-dev-guide/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 49f21cd47ac9d29ddefc265b5a4dae370d6adbe3 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Tue, 20 Jul 2021 17:39:41 -0700 Subject: [PATCH 1512/2516] Link directly to stabilization report comments (#1173) Previously, readers had to scroll through tons of comments to find the report. --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index a6203a3c60058..60d333a371c7a 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 2296fd8621a4cb7c517bae42b9e520e45d057160 Mon Sep 17 00:00:00 2001 From: Ben Reeves Date: Sun, 25 Jul 2021 17:37:28 -0500 Subject: [PATCH 1513/2516] Fix typo in building/bootstrapping.md (#1175) --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 61537dbf874fb..876c565abb3a5 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 5061a08d961ecebbdd4005e5168119482c1c3c1f Mon Sep 17 00:00:00 2001 From: Dave Date: Wed, 28 Jul 2021 18:05:43 +0430 Subject: [PATCH 1514/2516] git.md: Fix No-Merge Policy link --- src/doc/rustc-dev-guide/src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 1c311982cadc5..72d287151886a 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 d870ce2140e8683de2f7827f3f49ac9f75c302c5 Mon Sep 17 00:00:00 2001 From: the8472 Date: Thu, 29 Jul 2021 06:05:19 +0200 Subject: [PATCH 1515/2516] Add S-Inactive PRs as another source of things contributors could work on (#1177) --- src/doc/rustc-dev-guide/src/compiler-team.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/compiler-team.md b/src/doc/rustc-dev-guide/src/compiler-team.md index aac2634843151..abdeac3d25ac1 100644 --- a/src/doc/rustc-dev-guide/src/compiler-team.md +++ b/src/doc/rustc-dev-guide/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 9d5a487ffd2258ce275e9b752927844c4c8c916b Mon Sep 17 00:00:00 2001 From: Yoh Deadfall Date: Thu, 5 Aug 2021 14:41:16 +0300 Subject: [PATCH 1516/2516] Fixed team responsible for stabilization (#1181) --- src/doc/rustc-dev-guide/src/stability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 7eff3e88bc618..51d849200cde5 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 630c8fe7a3c933f7554ea4d786013d32fc0a2082 Mon Sep 17 00:00:00 2001 From: Bryan Cantrill Date: Sat, 7 Aug 2021 01:12:22 -0700 Subject: [PATCH 1517/2516] Add description of -opt-bisect-limit LLVM option (#1182) --- src/doc/rustc-dev-guide/src/backend/debugging.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/backend/debugging.md b/src/doc/rustc-dev-guide/src/backend/debugging.md index 7577a0e13dd02..6736601676506 100644 --- a/src/doc/rustc-dev-guide/src/backend/debugging.md +++ b/src/doc/rustc-dev-guide/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 d0c4cafdc2de7089e8ed51576e5e7119ae40d04b Mon Sep 17 00:00:00 2001 From: Rahul Butani Date: Tue, 10 Aug 2021 04:41:44 -0700 Subject: [PATCH 1518/2516] Remove a dead link in `new-target.md` + other nits (#1186) --- src/doc/rustc-dev-guide/src/building/new-target.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index 7701fdbac0a4c..9687541388977 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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 451084b3bd1f2981000e320c1f558c3f0e0dcecf Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 5 Aug 2021 08:54:28 +0200 Subject: [PATCH 1519/2516] allow to quickly edit a page directly on github --- src/doc/rustc-dev-guide/book.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index bad4fe1aa5f97..fb09c804e9a35 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 5d77984e03609c536ce6da5e5a76c5808ddc2e3c Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 16 Aug 2021 03:33:24 +0200 Subject: [PATCH 1520/2516] 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 --- src/doc/rustc-dev-guide/.github/workflows/ci.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/.github/workflows/ci.yml b/src/doc/rustc-dev-guide/.github/workflows/ci.yml index a2b9cc30d7050..fed51378cd1d8 100644 --- a/src/doc/rustc-dev-guide/.github/workflows/ci.yml +++ b/src/doc/rustc-dev-guide/.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 4cba5b3f720fd58e489f666cfefb86901dcdb6f9 Mon Sep 17 00:00:00 2001 From: Smitty Date: Wed, 4 Aug 2021 19:11:38 -0400 Subject: [PATCH 1521/2516] Remove docs for old -Z profile-queries flag --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 - .../rustc-dev-guide/src/queries/profiling.md | 346 ------------------ src/doc/rustc-dev-guide/src/query.md | 21 +- 3 files changed, 20 insertions(+), 348 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/queries/profiling.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 5fa267601241b..cb3b4b404f838 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/profiling.md b/src/doc/rustc-dev-guide/src/queries/profiling.md deleted file mode 100644 index 1160ba818861b..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 20e547b1e35db..24b0454b9ab71 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 281a814146ee4b5c9b1cdbeacc2cce1936283382 Mon Sep 17 00:00:00 2001 From: Smittyvb Date: Sat, 21 Aug 2021 19:55:56 -0400 Subject: [PATCH 1522/2516] 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/doc/rustc-dev-guide/src/thir.md | 190 +++++++++++++++++++++++++++- 1 file changed, 183 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/thir.md b/src/doc/rustc-dev-guide/src/thir.md index a1d38990792a8..95009e5529b24 100644 --- a/src/doc/rustc-dev-guide/src/thir.md +++ b/src/doc/rustc-dev-guide/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 97f6dfef2e07467078f2f2d967a08a90307e7766 Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Sun, 22 Aug 2021 16:47:02 +0200 Subject: [PATCH 1523/2516] =?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/doc/rustc-dev-guide/src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 24b0454b9ab71..7195687919d60 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 352185d7784e9bff513d63c60ecef665894e76aa Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Thu, 26 Aug 2021 16:34:43 -0700 Subject: [PATCH 1524/2516] date-check: Recognize capitalized 'Date' as well Now, if people use 'Date' instead of 'date', it won't be ignored. --- src/doc/rustc-dev-guide/ci/date-check/src/main.rs | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/date-check/src/main.rs b/src/doc/rustc-dev-guide/ci/date-check/src/main.rs index d78b430b5c71e..bbea2bf38d948 100644 --- a/src/doc/rustc-dev-guide/ci/date-check/src/main.rs +++ b/src/doc/rustc-dev-guide/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 6839dc5bf9f53ebd14f4c9d969cc076670177248 Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Sat, 28 Aug 2021 09:35:36 +0200 Subject: [PATCH 1526/2516] Fix warning "Renderer command uses a path relative to the renderer output directory ..." (#1194) --- src/doc/rustc-dev-guide/book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index fb09c804e9a35..f53ed45f61851 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 5575d62805dd79b15f8f6436984ceeea7f10bed1 Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Sat, 28 Aug 2021 13:26:16 +0200 Subject: [PATCH 1527/2516] 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/doc/rustc-dev-guide/src/rustdoc-internals.md | 4 ++-- src/doc/rustc-dev-guide/src/tests/adding.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index 2e06d5b1fba9c..a74078951ee54 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 8508c2f206d60..d9b063d5c4314 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 41fc234ac2c09480ba2cde92b691fa39c284b517 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Sat, 28 Aug 2021 15:07:20 -0700 Subject: [PATCH 1528/2516] Fix typo, clarify backtick wording, and use inline code --- src/doc/rustc-dev-guide/src/diagnostics.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 385d7db60fd8c..ca2ba13ca9ecf 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 0a8972aeb16eeebee716f0954a5d6a4342880109 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 31 Aug 2021 12:13:18 -0500 Subject: [PATCH 1529/2516] Add rustc-source to suggested rust-analyzer config (#1189) This allows loading the sources for crates loaded from the sysroot. --- src/doc/rustc-dev-guide/src/building/suggested.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index bb6badcd6e204..e544a68b8176b 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 e2f933df261a50d302a8fc5dd788f6ab23272bfa Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Tue, 31 Aug 2021 10:31:06 -0700 Subject: [PATCH 1530/2516] Add link to `Span` --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 8e5d5b3947386..6b3ec41966e03 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 3ba8fa3bc2ccecdf544b5e594613f2a30133501a Mon Sep 17 00:00:00 2001 From: Fridtjof Stoldt Date: Wed, 1 Sep 2021 20:26:58 +0200 Subject: [PATCH 1531/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/diagnostics/diagnostic-items.md | 146 ++++++++++++++++++ 2 files changed, 147 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index cb3b4b404f838..33dbbf7e22af2 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md new file mode 100644 index 0000000000000..efaa01cf396f1 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 1717971ad4f7332d8f2a10d11c35fc21a63d3f33 Mon Sep 17 00:00:00 2001 From: Dezhi Wu Date: Sun, 5 Sep 2021 20:40:35 +0800 Subject: [PATCH 1532/2516] Fix a typo (#1200) --- src/doc/rustc-dev-guide/src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 6c756e18ff58b..cabd4fc7dafe1 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 a2fe5e6d9687e96bcf1b2480906f256c34d30779 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 1533/2516] Spelling change intermidiate to intermediate Very importent change. --- src/doc/rustc-dev-guide/src/salsa.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index 9bf93727a3834..a6a6b97069173 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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 635374320256ce2503b518656ae8e168b324e409 Mon Sep 17 00:00:00 2001 From: Dezhi Wu Date: Tue, 7 Sep 2021 05:34:16 +0800 Subject: [PATCH 1534/2516] Add links to overview.md (#1202) --- src/doc/rustc-dev-guide/src/overview.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index cabd4fc7dafe1..2e4c695501ef8 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 01d3673c9d8b6c428215650972340284a807615d Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Mon, 6 Sep 2021 13:11:09 -0700 Subject: [PATCH 1535/2516] Docs: consolidated parallelism information --- src/doc/rustc-dev-guide/src/overview.md | 7 +-- src/doc/rustc-dev-guide/src/parallel-rustc.md | 61 ++++++++++++++----- .../query-evaluation-model-in-detail.md | 26 -------- 3 files changed, 47 insertions(+), 47 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 2e4c695501ef8..26b291d35fe56 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index eec8219a5b7fc..243dca98e00ac 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md b/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md index 4c2427e3c4eb6..b84a5dac42277 100644 --- a/src/doc/rustc-dev-guide/src/queries/query-evaluation-model-in-detail.md +++ b/src/doc/rustc-dev-guide/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 c6899fc8ef3c861523be17a3d68ec807260cf624 Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Mon, 6 Sep 2021 13:18:17 -0700 Subject: [PATCH 1536/2516] Docs: delete redundant use of correctness --- src/doc/rustc-dev-guide/src/parallel-rustc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index 243dca98e00ac..7f20078b93c98 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 27056b0cf2c7a1440ac8b26962ab530542aae843 Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Mon, 6 Sep 2021 13:42:56 -0700 Subject: [PATCH 1537/2516] Docs: added section discussing core ideas --- src/doc/rustc-dev-guide/src/parallel-rustc.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index 7f20078b93c98..a29e4f9745123 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 995489f95f6d79aa1e023341e42d396104af3e19 Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Mon, 6 Sep 2021 13:45:44 -0700 Subject: [PATCH 1538/2516] Docs: deleted copy --- src/doc/rustc-dev-guide/src/parallel-rustc.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index a29e4f9745123..67f349ac33168 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 dcf46e47009134e7c9ba844df316db07667a5909 Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Mon, 6 Sep 2021 16:08:07 -0700 Subject: [PATCH 1539/2516] Docs: made suggested fix --- src/doc/rustc-dev-guide/src/parallel-rustc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index 67f349ac33168..d1eff7ad70bd7 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 6daa71ca9c8919e5d1ad67622f9207955307f028 Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Tue, 7 Sep 2021 08:52:52 -0700 Subject: [PATCH 1540/2516] Docs: added section on rustdoc --- src/doc/rustc-dev-guide/src/parallel-rustc.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index d1eff7ad70bd7..38230377be1db 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 ea9efd8873d839d37fff0b3c15eaa44574c82d8c Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Wed, 8 Sep 2021 10:17:39 -0700 Subject: [PATCH 1541/2516] Clarify paragraph in "Keeping things up to date" --- src/doc/rustc-dev-guide/src/git.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 72d287151886a..ac03a3c0f7c7e 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 5776fe0e30d7c06b00b91939132ee3e2a29524d0 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 1542/2516] Delete ctags.md --- src/doc/rustc-dev-guide/src/building/ctags.md | 26 ------------------- 1 file changed, 26 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/building/ctags.md diff --git a/src/doc/rustc-dev-guide/src/building/ctags.md b/src/doc/rustc-dev-guide/src/building/ctags.md deleted file mode 100644 index 9b63314578d01..0000000000000 --- a/src/doc/rustc-dev-guide/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 4edd03e749e80bb94aae4ec4c9d4cdf3c6a73710 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 1543/2516] Move ctag section to "Suggested Workflow" --- .../rustc-dev-guide/src/building/suggested.md | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index e544a68b8176b..c05015851b209 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 85314a9470dd2a63ce1583b7c4b3e9053cd08b49 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 1544/2516] Update SUMMARY.md --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 33dbbf7e22af2..c69ad73a54764 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 ade4c626d4dfc3f9164a630b8f9922f76f34a1bd 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 1545/2516] Update suggested.md --- src/doc/rustc-dev-guide/src/building/suggested.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index c05015851b209..ac8127a42f761 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 6acf6c00c41c99fb076266c1488abcd6ec0dba82 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 1546/2516] remove ctag section --- .../rustc-dev-guide/src/building/suggested.md | 27 ------------------- 1 file changed, 27 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index ac8127a42f761..e544a68b8176b 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 8e42e56dd678855ce16dd9add73ce8fa333ce749 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sun, 12 Sep 2021 09:12:40 -0700 Subject: [PATCH 1547/2516] Clarify difference of a help vs note diagnostic. --- src/doc/rustc-dev-guide/src/diagnostics.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index ca2ba13ca9ecf..e35bde093a963 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 4e4e1f4a310af0252cfccd5c9dc405f8e3e7221e Mon Sep 17 00:00:00 2001 From: Sl1mb0 Date: Thu, 16 Sep 2021 18:58:07 -0700 Subject: [PATCH 1548/2516] 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/doc/rustc-dev-guide/src/parallel-rustc.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index 38230377be1db..2ee302d244cf4 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 1325d517f555d157acfdb98a46f17f57467495c3 Mon Sep 17 00:00:00 2001 From: lcnr Date: Fri, 17 Sep 2021 21:50:26 +0200 Subject: [PATCH 1549/2516] `ty::Unevaluated`: dealing with unused substs (#1190) * unused ct substs * q * q * Update src/constants.md Co-authored-by: Niko Matsakis --- src/doc/rustc-dev-guide/src/constants.md | 65 ++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/constants.md diff --git a/src/doc/rustc-dev-guide/src/constants.md b/src/doc/rustc-dev-guide/src/constants.md new file mode 100644 index 0000000000000..9e63a58cde78a --- /dev/null +++ b/src/doc/rustc-dev-guide/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 b0220ed1f071fb2121bd2c25d26fe7a0ab6a1bba Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Fri, 17 Sep 2021 21:48:36 +0200 Subject: [PATCH 1550/2516] Suggests `--edition=2018` argument when using stage0/bin/rustfmt directly --- src/doc/rustc-dev-guide/src/building/suggested.md | 5 +++-- src/doc/rustc-dev-guide/src/getting-started.md | 2 ++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index e544a68b8176b..eed267f9832b4 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 18e429e5ea494..14225c5046914 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 3f4a67efb94c5b385cd2da809d05285bacf8c8b3 Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Fri, 17 Sep 2021 23:33:54 +0200 Subject: [PATCH 1551/2516] Make indentation consistent in example vscode config file --- src/doc/rustc-dev-guide/src/building/suggested.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index eed267f9832b4..f1665efdc7825 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 9df9b6dfc153c..aca5b142ef403 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index a74078951ee54..112a5dcab765d 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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 c3c390f4f8de5fea0cb88754cfdcf9b06ed51a87 Mon Sep 17 00:00:00 2001 From: Janggun Lee Date: Wed, 6 Oct 2021 21:07:51 +0900 Subject: [PATCH 1556/2516] 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. --- .../rustc-dev-guide/src/borrow_check/two_phase_borrows.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md b/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md index a5e26c6a88ed3..bcd48782110a2 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/two_phase_borrows.md +++ b/src/doc/rustc-dev-guide/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 d6a3ab3cc1cb374680d48165f206b81b29c67a4d Mon Sep 17 00:00:00 2001 From: Eric Holk Date: Thu, 7 Oct 2021 10:23:23 -0700 Subject: [PATCH 1557/2516] 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/doc/rustc-dev-guide/src/closure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index 1d7f4bccdef11..20dccc8ab2e69 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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 ab3dba9a0261fb5066cc2beec9ea659b797a6c07 Mon Sep 17 00:00:00 2001 From: Eric Holk Date: Thu, 7 Oct 2021 15:13:58 -0700 Subject: [PATCH 1558/2516] Update src/closure.md Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/closure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md index 20dccc8ab2e69..a38e93241a91c 100644 --- a/src/doc/rustc-dev-guide/src/closure.md +++ b/src/doc/rustc-dev-guide/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 fcb1a70ecd59e3e5969e6591810bf0c2c5a36a7e Mon Sep 17 00:00:00 2001 From: Oli Scherer Date: Tue, 5 Oct 2021 09:57:35 +0000 Subject: [PATCH 1559/2516] Move log/tracing instructions to its own file --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../rustc-dev-guide/src/compiler-debugging.md | 135 +----------------- .../rustc-dev-guide/src/getting-started.md | 4 +- src/doc/rustc-dev-guide/src/tracing.md | 133 +++++++++++++++++ 4 files changed, 137 insertions(+), 136 deletions(-) create mode 100644 src/doc/rustc-dev-guide/src/tracing.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 5e59cf651c655..b7b6d8bd14873 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index 34f5e760f1d81..8f46e896eb303 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 14225c5046914..4d77b03dbe529 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tracing.md b/src/doc/rustc-dev-guide/src/tracing.md new file mode 100644 index 0000000000000..a676aaad04560 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 092edd44bf22d740730625d28b14546bff54b749 Mon Sep 17 00:00:00 2001 From: Oli Scherer Date: Tue, 5 Oct 2021 09:59:34 +0000 Subject: [PATCH 1560/2516] Document tracing awesomeness --- src/doc/rustc-dev-guide/src/tracing.md | 83 ++++++++++++++++++++++---- 1 file changed, 72 insertions(+), 11 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tracing.md b/src/doc/rustc-dev-guide/src/tracing.md index a676aaad04560..88c2886852878 100644 --- a/src/doc/rustc-dev-guide/src/tracing.md +++ b/src/doc/rustc-dev-guide/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 f2a1905391486461ea58fd67a5c8c3abad36ae03 Mon Sep 17 00:00:00 2001 From: Oli Scherer Date: Tue, 5 Oct 2021 10:15:26 +0000 Subject: [PATCH 1561/2516] Address review comments --- src/doc/rustc-dev-guide/src/tracing.md | 30 +++++++++++++++++--------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tracing.md b/src/doc/rustc-dev-guide/src/tracing.md index 88c2886852878..422d94c538bac 100644 --- a/src/doc/rustc-dev-guide/src/tracing.md +++ b/src/doc/rustc-dev-guide/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 c69f918740673a5871f5b5b3879546b8b9c78287 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 1562/2516] Mention needs-sanitizer-hwaddress directive --- src/doc/rustc-dev-guide/src/tests/adding.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index d9b063d5c4314..d1b19516f6b31 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 b25420587448621c10ac6ea69de0e2c75fba1560 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 1563/2516] Update sanitizer documentation --- src/doc/rustc-dev-guide/src/sanitizers.md | 72 ++++++++++++++++++----- 1 file changed, 57 insertions(+), 15 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/sanitizers.md b/src/doc/rustc-dev-guide/src/sanitizers.md index ce07140340f2a..49183d6d5e383 100644 --- a/src/doc/rustc-dev-guide/src/sanitizers.md +++ b/src/doc/rustc-dev-guide/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 f4708b660ce4ad989f2c36daa6dca997b9d0d253 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Sun, 19 Sep 2021 11:19:51 -0700 Subject: [PATCH 1564/2516] Recommend `rustfmt --edition=2021` --- src/doc/rustc-dev-guide/src/building/suggested.md | 2 +- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index f1665efdc7825..24e25f5d0508a 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 0ed4e95a01b20157dee63ab7a885b12ade8fdb4f Mon Sep 17 00:00:00 2001 From: Yusuke Abe Date: Tue, 12 Oct 2021 08:52:21 +0900 Subject: [PATCH 1565/2516] Update some docs from 2021-10 date triage (#1230) --- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/updating-llvm.md b/src/doc/rustc-dev-guide/src/backend/updating-llvm.md index 9deff62dd6fa8..1a6fa033a9a5b 100644 --- a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md index dfc4327e501df..c7c107e1ed9ff 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/member_constraints.md +++ b/src/doc/rustc-dev-guide/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 3bd8a0ed5298f5e8aca0004e5e6a8dcab4f286a5 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 17 Oct 2021 13:17:19 -0400 Subject: [PATCH 1566/2516] Remove docs on Assemble step (#1233) --- .../src/building/bootstrapping.md | 23 ++++--------------- 1 file changed, 4 insertions(+), 19 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 876c565abb3a5..26527ec9c9a37 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 effa9e2a61e6f5712e6056afee9e19a6b30e69d7 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 1567/2516] Describe how to trigger perf runs (#1237) --- src/doc/rustc-dev-guide/src/profiling.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index ca0fee6d571d5..4851e3ee9d339 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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 30ed0914db52e489e2ff05c60ecdc972f5da6ad0 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Thu, 21 Oct 2021 12:52:19 -0700 Subject: [PATCH 1568/2516] Switch date-check to Rust 2021 No migrations were necessary. --- src/doc/rustc-dev-guide/ci/date-check/Cargo.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/date-check/Cargo.toml b/src/doc/rustc-dev-guide/ci/date-check/Cargo.toml index 95251fb12335d..884f485fad543 100644 --- a/src/doc/rustc-dev-guide/ci/date-check/Cargo.toml +++ b/src/doc/rustc-dev-guide/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 56748c3e4bd1bf4f7084c6ff91d0ac6eae08f437 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Thu, 21 Oct 2021 12:53:03 -0700 Subject: [PATCH 1569/2516] Update author field --- src/doc/rustc-dev-guide/ci/date-check/Cargo.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/ci/date-check/Cargo.toml b/src/doc/rustc-dev-guide/ci/date-check/Cargo.toml index 884f485fad543..472529511d062 100644 --- a/src/doc/rustc-dev-guide/ci/date-check/Cargo.toml +++ b/src/doc/rustc-dev-guide/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 9b6d89841ea48a8b32d0826f7837abef740d7294 Mon Sep 17 00:00:00 2001 From: Ramon de C Valle Date: Thu, 14 Oct 2021 15:52:44 -0700 Subject: [PATCH 1570/2516] 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/doc/rustc-dev-guide/src/sanitizers.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/sanitizers.md b/src/doc/rustc-dev-guide/src/sanitizers.md index 49183d6d5e383..a088d62eda0ab 100644 --- a/src/doc/rustc-dev-guide/src/sanitizers.md +++ b/src/doc/rustc-dev-guide/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 16ce294eb9b78601dd38979ca637024d0444bf67 Mon Sep 17 00:00:00 2001 From: Janggun Lee Date: Fri, 29 Oct 2021 00:58:26 +0900 Subject: [PATCH 1571/2516] 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 +++--- .../rustc-dev-guide/src/backend/monomorph.md | 10 ++--- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/const-eval.md | 4 +- .../src/llvm-coverage-instrumentation.md | 40 +++++++++---------- src/doc/rustc-dev-guide/src/mir/dataflow.md | 22 +++++----- src/doc/rustc-dev-guide/src/mir/debugging.md | 2 +- src/doc/rustc-dev-guide/src/mir/index.md | 8 +++- .../rustc-dev-guide/src/mir/optimizations.md | 21 +++++----- src/doc/rustc-dev-guide/src/mir/passes.md | 7 ++-- src/doc/rustc-dev-guide/src/mir/visitor.md | 3 +- src/doc/rustc-dev-guide/src/miri.md | 14 +++---- src/doc/rustc-dev-guide/src/overview.md | 10 ++--- .../src/profiling/with_perf.md | 18 ++++----- 18 files changed, 122 insertions(+), 115 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md b/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md index 02eea5bab6415..21554f5a40152 100644 --- a/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index 0457c18412ba0..0dc8054311862 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check.md b/src/doc/rustc-dev-guide/src/borrow_check.md index 7e076edf37f9a..8e2bb752ae688 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md b/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md index e38b923cf372f..4afec42f83d59 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md index f0a7f73535afa..4c30d25e0406f 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index c65b8ce5a54ac..369ce2d3d0adb 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/type_check.md b/src/doc/rustc-dev-guide/src/borrow_check/type_check.md index 0db895619eb74..1485f2ae87c18 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/type_check.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/const-eval.md b/src/doc/rustc-dev-guide/src/const-eval.md index d21d0ea58172a..5a11f8cddf14b 100644 --- a/src/doc/rustc-dev-guide/src/const-eval.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 7d3c0fe360fb2..3dd565b59b1e8 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index 61277846ba294..0e626d97c6577 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/debugging.md b/src/doc/rustc-dev-guide/src/mir/debugging.md index b7182fa900ec4..84030b139946c 100644 --- a/src/doc/rustc-dev-guide/src/mir/debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index 306d2abfd270d..d3bceae47dde4 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index 50e06960ed592..9ecf4e0d30404 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/passes.md b/src/doc/rustc-dev-guide/src/mir/passes.md index b847584b1b5b2..5528b77624cdd 100644 --- a/src/doc/rustc-dev-guide/src/mir/passes.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/visitor.md b/src/doc/rustc-dev-guide/src/mir/visitor.md index c80462b953f0d..5c21d5304ac04 100644 --- a/src/doc/rustc-dev-guide/src/mir/visitor.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index c19ba6401249f..50bbb4b56d674 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 26b291d35fe56..bf64d0e56cade 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index b383ec542b760..85f6601ad6a9b 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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 52a1d9b4f6f6d6e4b7110335d153cf0785abf115 Mon Sep 17 00:00:00 2001 From: pierwill Date: Thu, 28 Oct 2021 11:41:04 -0500 Subject: [PATCH 1572/2516] Edit "About this guide" for semantic line feeds This is work toward #1241. --- .../rustc-dev-guide/src/about-this-guide.md | 60 ++++++++++--------- 1 file changed, 31 insertions(+), 29 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index 3fa397ae4082a..f4c5c81d1b39c 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 9160d76d5362ff246dd45a57f368b78c97f6f0f9 Mon Sep 17 00:00:00 2001 From: xFrednet Date: Thu, 28 Oct 2021 18:30:49 +0200 Subject: [PATCH 1573/2516] Some minor adjustments to the diagnostic documentation --- src/doc/rustc-dev-guide/src/diagnostics.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index e35bde093a963..20dbefd7b0690 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 3e470fcf63e27001b217d1ea15b799d0ea77efbe Mon Sep 17 00:00:00 2001 From: pierwill Date: Sat, 23 Oct 2021 23:15:54 -0500 Subject: [PATCH 1574/2516] 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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 26527ec9c9a37..b6f9db74ccb14 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 24837dd684d8e60fbdd0ebea8793b0ebb77eb074 Mon Sep 17 00:00:00 2001 From: Caleb Cartwright Date: Mon, 1 Nov 2021 21:31:19 -0500 Subject: [PATCH 1575/2516] enhance subtree docs, link to clippy docs --- src/doc/rustc-dev-guide/src/contributing.md | 42 +++++++++++---------- 1 file changed, 23 insertions(+), 19 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index aca5b142ef403..91817904d48bf 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 ff167cfd3b9c479171e4b6ecef507d309e209fd4 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Wed, 3 Nov 2021 12:22:15 -0700 Subject: [PATCH 1576/2516] 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 --- src/doc/rustc-dev-guide/.github/workflows/date-check.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/doc/rustc-dev-guide/.github/workflows/date-check.yml b/src/doc/rustc-dev-guide/.github/workflows/date-check.yml index c787da07122d2..b808876a42d16 100644 --- a/src/doc/rustc-dev-guide/.github/workflows/date-check.yml +++ b/src/doc/rustc-dev-guide/.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 e679209aac11cc1e82a6b131a7b0a68533feafad Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Wed, 3 Nov 2021 12:24:50 -0700 Subject: [PATCH 1577/2516] Update some date-check comments I removed one of them because it doesn't seem necessary. --- src/doc/rustc-dev-guide/src/overview.md | 2 +- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 2 +- src/doc/rustc-dev-guide/src/tests/intro.md | 3 +-- 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index bf64d0e56cade..5c0732f3746a2 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index 112a5dcab765d..0d7459b1d3cf4 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 6419133455829..3f8ec97ee7bd9 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 57d831b27b70bd66d4e133cca2df06b3bc64815d Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Thu, 4 Nov 2021 09:30:35 -0700 Subject: [PATCH 1578/2516] Fix date Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 5c0732f3746a2..5c88722ef3441 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 3a6e42eda4f740e951712b1be0e6907c850b878a Mon Sep 17 00:00:00 2001 From: Dmitry Savintsev Date: Thu, 4 Nov 2021 18:50:37 +0100 Subject: [PATCH 1579/2516] tiny capitalization fix --- src/doc/rustc-dev-guide/src/about-this-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index f4c5c81d1b39c..e015302c0561a 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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 621b3a447f0f98829d8b42cc9efaaa82a7c35060 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 3 Nov 2021 17:36:35 -0700 Subject: [PATCH 1580/2516] Remove some legacy test suites. --- src/doc/rustc-dev-guide/src/compiletest.md | 6 +++--- src/doc/rustc-dev-guide/src/tests/adding.md | 1 - 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index 2e0bcec538bda..b85aa09c2f2ce 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index d1b19516f6b31..34bd6f20ee389 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 f334ea94948528d5b6b9497c798e3b031dde3479 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 1581/2516] Add note to emphasize replacing TARGET_TRIPLE (#1250) --- src/doc/rustc-dev-guide/src/building/suggested.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 24e25f5d0508a..284317af71e49 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 159c89373208953779ecfc1c687e757707224934 Mon Sep 17 00:00:00 2001 From: Lucas Kent Date: Sun, 14 Nov 2021 14:12:13 +1100 Subject: [PATCH 1584/2516] Fix compare-mode documentation --- src/doc/rustc-dev-guide/src/tests/running.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 34a44f9c24c13..ca5b7f3ac2824 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 dc645fb25abbe63bd90599fe1226fbf6ba0ad1cd Mon Sep 17 00:00:00 2001 From: Lucas Kent Date: Tue, 16 Nov 2021 00:37:13 +1100 Subject: [PATCH 1585/2516] Spelling fixes --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 2 +- src/doc/rustc-dev-guide/src/backend/monomorph.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics/lintstore.md | 2 +- src/doc/rustc-dev-guide/src/early-late-bound.md | 2 +- src/doc/rustc-dev-guide/src/git.md | 2 +- src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md | 2 +- src/doc/rustc-dev-guide/src/macro-expansion.md | 2 +- src/doc/rustc-dev-guide/src/mir/debugging.md | 2 +- src/doc/rustc-dev-guide/src/mir/index.md | 2 +- src/doc/rustc-dev-guide/src/miri.md | 2 +- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 2 +- src/doc/rustc-dev-guide/src/tests/running.md | 2 +- src/doc/rustc-dev-guide/src/tracing.md | 4 ++-- src/doc/rustc-dev-guide/src/ty.md | 2 +- 14 files changed, 15 insertions(+), 15 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 6b3ec41966e03..4eba27fce2c2e 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index 0dc8054311862..a2918b6082a5a 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index d2796c07049d4..b544d2b6d62ad 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/early-late-bound.md b/src/doc/rustc-dev-guide/src/early-late-bound.md index 4178a4af0590c..29b2136b4c4cb 100644 --- a/src/doc/rustc-dev-guide/src/early-late-bound.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index ac03a3c0f7c7e..40f846d6abc9c 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 3dd565b59b1e8..4a0f53bfa1575 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index ce82852832058..2f42ad9b9e733 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/debugging.md b/src/doc/rustc-dev-guide/src/mir/debugging.md index 84030b139946c..3da17785bb707 100644 --- a/src/doc/rustc-dev-guide/src/mir/debugging.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/index.md b/src/doc/rustc-dev-guide/src/mir/index.md index d3bceae47dde4..0c00928c0cb57 100644 --- a/src/doc/rustc-dev-guide/src/mir/index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index 50bbb4b56d674..dd54f6548399b 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 85f6601ad6a9b..af30b47325272 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index ca5b7f3ac2824..19925fe27bac8 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tracing.md b/src/doc/rustc-dev-guide/src/tracing.md index 422d94c538bac..63d68e541268a 100644 --- a/src/doc/rustc-dev-guide/src/tracing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 9ee2ccfe2d0ac..87d653a745777 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 1833366ad679907551c7ddfec181c2d56f9dc70e 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 1586/2516] 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 +- .../rustc-dev-guide/src/building/suggested.md | 8 ++--- src/doc/rustc-dev-guide/src/contributing.md | 32 +++++++++---------- .../rustc-dev-guide/src/getting-started.md | 32 +++++++++---------- src/doc/rustc-dev-guide/src/git.md | 2 +- src/doc/rustc-dev-guide/src/profiling.md | 4 +-- src/doc/rustc-dev-guide/src/tests/intro.md | 2 +- src/doc/rustc-dev-guide/src/tests/running.md | 2 +- 13 files changed, 56 insertions(+), 56 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md b/src/doc/rustc-dev-guide/src/backend/updating-llvm.md index 1a6fa033a9a5b..0de0767b6d276 100644 --- a/src/doc/rustc-dev-guide/src/backend/updating-llvm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index e4dcc5ab2fa7a..fc1ad6c000207 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/build-install-distribution-artifacts.md b/src/doc/rustc-dev-guide/src/building/build-install-distribution-artifacts.md index 7430ffb9b8dc0..4ec3f958a05dd 100644 --- a/src/doc/rustc-dev-guide/src/building/build-install-distribution-artifacts.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/compiler-documenting.md b/src/doc/rustc-dev-guide/src/building/compiler-documenting.md index af3cd7ce289b5..0efe2fce617bd 100644 --- a/src/doc/rustc-dev-guide/src/building/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 49c2e8b6649f1..981bb6e50e07d 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index 9687541388977..b5fc2cb0ad261 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 284317af71e49..bae98aa0412bf 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index 4851e3ee9d339..fd7014224d0b4 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 3f8ec97ee7bd9..25c1d059c171e 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 19925fe27bac8..2e1ce0a910423 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 433cbfde9bc44b1c283f08b53e66a9864d8c01de Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 16 Nov 2021 22:43:17 +0900 Subject: [PATCH 1587/2516] 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/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index e14bc4157996a..cfb32bf07f7aa 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md index 369ce2d3d0adb..2dbbc0c1e267f 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/doc/rustc-dev-guide/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 28d0356ab23e832db981ef1897ecfabe11759ad6 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 1588/2516] Fix an invalid link on Diagnostic Items (#1261) --- src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md index efaa01cf396f1..93a0194d9f224 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md +++ b/src/doc/rustc-dev-guide/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 90c949fd6df98177a918223b88ba6e9b73b487b3 Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Thu, 18 Nov 2021 10:31:13 -0800 Subject: [PATCH 1589/2516] Describe drop elaboration (#1240) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/mir/drop-elaboration.md | 195 ++++++++++++++++++ 2 files changed, 196 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/mir/drop-elaboration.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index b7b6d8bd14873..411387ab63543 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/drop-elaboration.md b/src/doc/rustc-dev-guide/src/mir/drop-elaboration.md new file mode 100644 index 0000000000000..20b92cc45a887 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 d199d090b6243a35f9b488d0c4a675f390c55fde Mon Sep 17 00:00:00 2001 From: Simon Perriard Date: Wed, 24 Nov 2021 10:03:36 +0100 Subject: [PATCH 1590/2516] make it compile with 1.56.0 --- src/doc/rustc-dev-guide/examples/rustc-driver-example.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs index 51af6f5aab2a2..29fa24784ffcf 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs +++ b/src/doc/rustc-dev-guide/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 5c79aa782faf1c7705efffcbc88120b74d940306 Mon Sep 17 00:00:00 2001 From: Simon Perriard Date: Wed, 24 Nov 2021 10:07:12 +0100 Subject: [PATCH 1591/2516] 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/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs index 2c7533498078a..cbf48c9ceba71 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs +++ b/src/doc/rustc-dev-guide/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 81d42b558b7757eab0d938e3cf802721b68b4fe4 Mon Sep 17 00:00:00 2001 From: Simon Perriard Date: Wed, 24 Nov 2021 10:19:29 +0100 Subject: [PATCH 1592/2516] 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/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs index ee9a20c059513..d1b42658e1c0f 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs +++ b/src/doc/rustc-dev-guide/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 d9658734c582ab0cc3d3c7854c433e2cf58352d2 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 4 Nov 2021 11:09:14 -0700 Subject: [PATCH 1593/2516] Document more compiletest headers. --- src/doc/rustc-dev-guide/src/tests/adding.md | 48 +++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 34bd6f20ee389..3d67a539019d5 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 85a1f28ef335251b1d08378202694b939f4fbeee Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 4 Nov 2021 20:31:39 -0700 Subject: [PATCH 1594/2516] Apply suggestions from pierwill Co-authored-by: pierwill <19642016+pierwill@users.noreply.github.com> --- src/doc/rustc-dev-guide/src/tests/adding.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 3d67a539019d5..7e8ff9e988116 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 c5b2607316cff06e2397dba1984c8b9e7b28ff33 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 5 Nov 2021 07:15:03 -0700 Subject: [PATCH 1595/2516] Document rustfix-only-machine-applicable --- src/doc/rustc-dev-guide/src/tests/adding.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index 7e8ff9e988116..f99363a35865d 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 bb80ff17da455133588c7b903c02a89901300452 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 19 Nov 2021 13:54:01 -0800 Subject: [PATCH 1596/2516] Update for review comments. --- src/doc/rustc-dev-guide/src/tests/adding.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index f99363a35865d..d7ad2871df49f 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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 fbe824dda04a36d1c03f21f9d807580de855fd18 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 16 Nov 2021 08:36:33 +0900 Subject: [PATCH 1597/2516] Fix some links --- src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md | 5 ++--- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 2 +- src/doc/rustc-dev-guide/src/constants.md | 2 +- 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md b/src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md index d2cf8b6929ca5..5e005c965ede2 100644 --- a/src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index fc1ad6c000207..460776e51a040 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/constants.md b/src/doc/rustc-dev-guide/src/constants.md index 137351c22f8a9..30c0da736f931 100644 --- a/src/doc/rustc-dev-guide/src/constants.md +++ b/src/doc/rustc-dev-guide/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 99e213a27401b720cb4f442fa94a96c1da6c5bc9 Mon Sep 17 00:00:00 2001 From: Lucas Kent Date: Sat, 27 Nov 2021 16:28:44 +1100 Subject: [PATCH 1598/2516] Improve 'Running tests manually' section --- .../rustc-dev-guide/src/building/how-to-build-and-run.md | 5 +++++ src/doc/rustc-dev-guide/src/tests/running.md | 6 ++++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 981bb6e50e07d..ae3aabf129a29 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 2e1ce0a910423..c91a27bf2d160 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 d6f4a6b3916ca8a44ea0aa96e66db47be5572768 Mon Sep 17 00:00:00 2001 From: Rich Kadel Date: Fri, 3 Dec 2021 09:26:47 -0800 Subject: [PATCH 1599/2516] 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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 4a0f53bfa1575..cb3be57ac070a 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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 6f67d9c76364f41e7310e78ab11f3103b58181ad Mon Sep 17 00:00:00 2001 From: Lucas Kent Date: Sun, 5 Dec 2021 20:58:33 +1100 Subject: [PATCH 1600/2516] Improve documentation on r? --- src/doc/rustc-dev-guide/src/contributing.md | 17 ++++++++++++++++- src/doc/rustc-dev-guide/src/getting-started.md | 12 ++++++------ src/doc/rustc-dev-guide/src/walkthrough.md | 2 +- 3 files changed, 23 insertions(+), 8 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 6be8802c7cd2b..9c22fab9a4fab 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index f8273d631f05b..c150849f8eafd 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 5841afe4f54a8..8f5dc525ec9ac 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 72b6973b3eb97ab56c8ad056c9fbe60d0ffafb1a Mon Sep 17 00:00:00 2001 From: Lucas Kent Date: Tue, 7 Dec 2021 13:15:13 +1100 Subject: [PATCH 1601/2516] Update src/getting-started.md Co-authored-by: Joshua Nelson --- src/doc/rustc-dev-guide/src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index c150849f8eafd..a2f507e760200 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 01fbac497842d7b8aa814e33ce64a11a67c9cf2a Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Sat, 4 Dec 2021 17:59:42 -0800 Subject: [PATCH 1602/2516] Fix some broken links --- src/doc/rustc-dev-guide/src/mir/optimizations.md | 4 ++-- src/doc/rustc-dev-guide/src/profiling.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index 9ecf4e0d30404..add22c6fcf5f0 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index fd7014224d0b4..8db30b2537640 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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 7b6163bb6a185b8ef73f44ad99f575ec369ee301 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Sat, 4 Dec 2021 18:22:01 -0800 Subject: [PATCH 1603/2516] Update HIR chapter to use `HirId` instead of `NodeId` `NodeId`s are no longer used in the HIR. See #50928 for more information. --- src/doc/rustc-dev-guide/src/hir.md | 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 51e18973b8cd7..8316f7ce34d4a 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/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 26761ca47c541ac1d584f2fcf83b04c37dbbdb54 Mon Sep 17 00:00:00 2001 From: Jacob Hoffman-Andrews Date: Sat, 4 Dec 2021 23:28:05 -0800 Subject: [PATCH 1604/2516] Update rustdoc internals Use current paths when discussing source files. Update cheat sheet section with download-rustc. Add "use cases" section. --- src/doc/rustc-dev-guide/src/rustdoc.md | 131 +++++++++++++++++++++++-- 1 file changed, 121 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 2123d2b748d0c..66cb496dcb6cb 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 2faf199db5e5d6ade849f6afead746c772d8c307 Mon Sep 17 00:00:00 2001 From: Badel2 <2badel2@gmail.com> Date: Mon, 13 Dec 2021 07:16:30 +0100 Subject: [PATCH 1605/2516] Fix some broken links (#1274) --- src/doc/rustc-dev-guide/src/profiling.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index 8db30b2537640..ae76d977fd82a 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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 b67deeaf82a0295e56908fb0ce061aa0986d4819 Mon Sep 17 00:00:00 2001 From: Maxwell Elliot Heiber Date: Wed, 15 Dec 2021 15:36:10 +0000 Subject: [PATCH 1606/2516] Update humor docs for special-casing ferris emoji update for: https://github.com/rust-lang/rust/pull/91476/files --- src/doc/rustc-dev-guide/src/appendix/humorust.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md index a7ba61769929a..c502527d5b523 100644 --- a/src/doc/rustc-dev-guide/src/appendix/humorust.md +++ b/src/doc/rustc-dev-guide/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 8e224691c05d46705aa64f30aad1036c6deeac4b Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Wed, 15 Dec 2021 10:58:41 -0800 Subject: [PATCH 1607/2516] Move date-check comment to fix Markdown syntax The inline code wasn't being rendered correctly. --- src/doc/rustc-dev-guide/src/rustdoc-internals.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index 0d7459b1d3cf4..ccf0fcc5feb50 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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 404a87fdaaa09c47744ec2768d96cdb281ae2464 Mon Sep 17 00:00:00 2001 From: Wang Qilin Date: Mon, 20 Dec 2021 20:53:57 +0800 Subject: [PATCH 1608/2516] remove rustfix item in test intro (#1277) --- src/doc/rustc-dev-guide/src/tests/intro.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 25c1d059c171e..d92f042e4e404 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 5e01fd4f2e02590794c491eff94a93085c4f5840 Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Sat, 25 Dec 2021 02:52:31 +1100 Subject: [PATCH 1609/2516] 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 ++++- .../rustc-dev-guide/src/getting-started.md | 136 +++--------------- 3 files changed, 89 insertions(+), 138 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index ae3aabf129a29..4fe1da6d0ae75 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index be5d96ad9b677..ec2e8a8604234 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index a2f507e760200..40e68cf0eeb91 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 25d51ec375a4e87a41e9ac1b78ad174ffd77bfd1 Mon Sep 17 00:00:00 2001 From: Ben Reeves Date: Mon, 27 Dec 2021 10:28:15 -0600 Subject: [PATCH 1610/2516] Fix link in contributing.md (#1280) --- src/doc/rustc-dev-guide/src/contributing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 9c22fab9a4fab..8f6d1d6d8a275 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 5f6047b87904741273949d33546b624488ca386c Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Tue, 28 Dec 2021 20:17:49 -0800 Subject: [PATCH 1611/2516] Update link to moved section (#1282) The section was removed in #1030 and re-added in a different place in 2d42cf7. --- src/doc/rustc-dev-guide/src/building/prerequisites.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index ec2e8a8604234..cfe4c7738386b 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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 2413da5b477f4660138d8476b4ab4744c89d7a66 Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Wed, 5 Jan 2022 13:59:15 +1100 Subject: [PATCH 1612/2516] 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/doc/rustc-dev-guide/src/conventions.md | 22 ++- .../rustc-dev-guide/src/getting-started.md | 174 ++---------------- src/doc/rustc-dev-guide/src/rustdoc.md | 10 +- src/doc/rustc-dev-guide/src/tests/running.md | 11 ++ 5 files changed, 58 insertions(+), 182 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 4fe1da6d0ae75..3396627803b04 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 582de036493ba..0b0a951c3d6ca 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 40e68cf0eeb91..2b780ac4b66c8 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 66cb496dcb6cb..6c30a556c3539 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index c91a27bf2d160..a204fcab05764 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 7e1fed579d418413535f4aadf74534f975087515 Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Thu, 6 Jan 2022 11:39:57 +1100 Subject: [PATCH 1613/2516] Address review comments in #1286. --- src/doc/rustc-dev-guide/src/conventions.md | 5 ++--- src/doc/rustc-dev-guide/src/getting-started.md | 4 ++-- src/doc/rustc-dev-guide/src/rustdoc.md | 1 - src/doc/rustc-dev-guide/src/tests/running.md | 4 ---- 4 files changed, 4 insertions(+), 10 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 0b0a951c3d6ca..16828c49677e3 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index 2b780ac4b66c8..a5e67456ee739 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index 6c30a556c3539..d6063de73d48b 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index a204fcab05764..ba87c5f9ad2a5 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 6312d533f754ce406c54bffca9eee67a7717eb50 Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Thu, 6 Jan 2022 12:52:38 +1100 Subject: [PATCH 1614/2516] Address more review comments in #1286. --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- src/doc/rustc-dev-guide/src/rustdoc.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 3396627803b04..cd4891358168a 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustdoc.md b/src/doc/rustc-dev-guide/src/rustdoc.md index d6063de73d48b..7d07c041407b6 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc.md +++ b/src/doc/rustc-dev-guide/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 b8cea7bfbf63a39b906dde1685478d638537db40 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Tue, 18 Jan 2022 06:09:16 -0800 Subject: [PATCH 1615/2516] 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/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 03da8762016dd..73a3543cd44b7 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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 5ace24071f078464a432bb0c65f9e05696fe05a9 Mon Sep 17 00:00:00 2001 From: Georgiy Komarov Date: Tue, 18 Jan 2022 17:09:37 +0300 Subject: [PATCH 1616/2516] Spelling: Rename `rust` to `Rust` (#1288) --- .../rustc-dev-guide/src/about-this-guide.md | 4 ++-- .../rustc-dev-guide/src/backend/codegen.md | 2 +- .../rustc-dev-guide/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 +++--- .../rustc-dev-guide/src/building/suggested.md | 2 +- src/doc/rustc-dev-guide/src/compiler-src.md | 4 ++-- src/doc/rustc-dev-guide/src/compiletest.md | 2 +- src/doc/rustc-dev-guide/src/contributing.md | 2 +- src/doc/rustc-dev-guide/src/crates-io.md | 2 +- .../src/diagnostics/diagnostic-items.md | 2 +- .../rustc-dev-guide/src/macro-expansion.md | 2 +- src/doc/rustc-dev-guide/src/overview.md | 4 ++-- .../src/test-implementation.md | 2 +- src/doc/rustc-dev-guide/src/tests/intro.md | 4 ++-- src/doc/rustc-dev-guide/src/tests/running.md | 2 +- src/doc/rustc-dev-guide/src/ty.md | 2 +- src/doc/rustc-dev-guide/src/walkthrough.md | 20 +++++++++---------- 19 files changed, 35 insertions(+), 35 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/about-this-guide.md b/src/doc/rustc-dev-guide/src/about-this-guide.md index e015302c0561a..b2c71866c83cf 100644 --- a/src/doc/rustc-dev-guide/src/about-this-guide.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/codegen.md b/src/doc/rustc-dev-guide/src/backend/codegen.md index 8e18ca2426c11..1a6c2fa767c0f 100644 --- a/src/doc/rustc-dev-guide/src/backend/codegen.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index a2918b6082a5a..7111c634a33e7 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 460776e51a040..48f501a02392b 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/compiler-documenting.md b/src/doc/rustc-dev-guide/src/building/compiler-documenting.md index 0efe2fce617bd..f921cd0895ca4 100644 --- a/src/doc/rustc-dev-guide/src/building/compiler-documenting.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index cd4891358168a..93ebb487e39a3 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index bae98aa0412bf..14e0410ded1b5 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiler-src.md b/src/doc/rustc-dev-guide/src/compiler-src.md index b621dde7c202b..94add9aac1e3a 100644 --- a/src/doc/rustc-dev-guide/src/compiler-src.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md index b85aa09c2f2ce..2d34ea04ff71f 100644 --- a/src/doc/rustc-dev-guide/src/compiletest.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 8f6d1d6d8a275..2d65113219c1e 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/crates-io.md b/src/doc/rustc-dev-guide/src/crates-io.md index bc59bfeeda02a..62143defa6e2f 100644 --- a/src/doc/rustc-dev-guide/src/crates-io.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md index 93a0194d9f224..b5cba717fc796 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 2f42ad9b9e733..e3b5a27e6b235 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 5c88722ef3441..02e56ca03a666 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/test-implementation.md b/src/doc/rustc-dev-guide/src/test-implementation.md index 1a9283b5976da..09a66cdc91c05 100644 --- a/src/doc/rustc-dev-guide/src/test-implementation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index d92f042e4e404..efce3a6580e47 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index ba87c5f9ad2a5..cd8f12ba19412 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 87d653a745777..95141b6f28851 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md index 8f5dc525ec9ac..84cb1296f208d 100644 --- a/src/doc/rustc-dev-guide/src/walkthrough.md +++ b/src/doc/rustc-dev-guide/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 e292a4eefb4c77a53e3546c7d3ede86e71015687 Mon Sep 17 00:00:00 2001 From: Amanieu d'Antras Date: Tue, 18 Jan 2022 14:12:06 +0000 Subject: [PATCH 1617/2516] Add inline assembly internals (#1266) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 1 + src/doc/rustc-dev-guide/src/asm.md | 367 +++++++++++++++++++++++++ 2 files changed, 368 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/asm.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 411387ab63543..fa044bce5a922 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/asm.md b/src/doc/rustc-dev-guide/src/asm.md new file mode 100644 index 0000000000000..2c177164e937f --- /dev/null +++ b/src/doc/rustc-dev-guide/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 d150d90169ba0c11d8e5d13d74ccbd6fca7f149c Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 18 Jan 2022 09:44:26 -0800 Subject: [PATCH 1618/2516] Reorganize and expand the testing chapters. (#1281) * Reorganize and expand the testing chapters. * Update tests chapters for review comments. * Fix typo. --- src/doc/rustc-dev-guide/book.toml | 3 + src/doc/rustc-dev-guide/src/SUMMARY.md | 10 +- src/doc/rustc-dev-guide/src/compiletest.md | 223 ------ src/doc/rustc-dev-guide/src/profiling.md | 7 +- src/doc/rustc-dev-guide/src/tests/adding.md | 663 ++++-------------- src/doc/rustc-dev-guide/src/tests/ci.md | 73 ++ .../rustc-dev-guide/src/tests/compiletest.md | 526 ++++++++++++++ src/doc/rustc-dev-guide/src/tests/crater.md | 45 ++ src/doc/rustc-dev-guide/src/tests/docker.md | 52 ++ src/doc/rustc-dev-guide/src/tests/headers.md | 403 +++++++++++ src/doc/rustc-dev-guide/src/tests/intro.md | 464 ++++-------- src/doc/rustc-dev-guide/src/tests/perf.md | 50 ++ src/doc/rustc-dev-guide/src/tests/running.md | 136 +++- src/doc/rustc-dev-guide/src/tests/ui.md | 500 +++++++++++++ 14 files changed, 2055 insertions(+), 1100 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/compiletest.md create mode 100644 src/doc/rustc-dev-guide/src/tests/ci.md create mode 100644 src/doc/rustc-dev-guide/src/tests/compiletest.md create mode 100644 src/doc/rustc-dev-guide/src/tests/crater.md create mode 100644 src/doc/rustc-dev-guide/src/tests/docker.md create mode 100644 src/doc/rustc-dev-guide/src/tests/headers.md create mode 100644 src/doc/rustc-dev-guide/src/tests/perf.md create mode 100644 src/doc/rustc-dev-guide/src/tests/ui.md diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index f53ed45f61851..336e5a3695c37 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index fa044bce5a922..3189b93644629 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/compiletest.md b/src/doc/rustc-dev-guide/src/compiletest.md deleted file mode 100644 index 2d34ea04ff71f..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index ae76d977fd82a..0d333f7be88d4 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/adding.md b/src/doc/rustc-dev-guide/src/tests/adding.md index d7ad2871df49f..2fb1e0b65e0d0 100644 --- a/src/doc/rustc-dev-guide/src/tests/adding.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/ci.md b/src/doc/rustc-dev-guide/src/tests/ci.md new file mode 100644 index 0000000000000..21f8341306df6 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/compiletest.md b/src/doc/rustc-dev-guide/src/tests/compiletest.md new file mode 100644 index 0000000000000..b54bdfcfd8566 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/crater.md b/src/doc/rustc-dev-guide/src/tests/crater.md new file mode 100644 index 0000000000000..9a7ff38715b5c --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/docker.md b/src/doc/rustc-dev-guide/src/tests/docker.md new file mode 100644 index 0000000000000..29837dfea4b8b --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/headers.md b/src/doc/rustc-dev-guide/src/tests/headers.md new file mode 100644 index 0000000000000..adc5fa6c9b68e --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index efce3a6580e47..65facccbaad1c 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/perf.md b/src/doc/rustc-dev-guide/src/tests/perf.md new file mode 100644 index 0000000000000..ac65faff1fb6d --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index cd8f12ba19412..2e823c0edda5b 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/ui.md b/src/doc/rustc-dev-guide/src/tests/ui.md new file mode 100644 index 0000000000000..a8e8d3b7209a2 --- /dev/null +++ b/src/doc/rustc-dev-guide/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 6f308aee135fa04afd5f56446fe6be0199b81f11 Mon Sep 17 00:00:00 2001 From: Ivor Wanders Date: Thu, 20 Jan 2022 18:17:31 -0500 Subject: [PATCH 1619/2516] Clarify that r? works in comments. --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 2d65113219c1e..0c6b15da3eef8 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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 7eb0df9b15325ea03c3e98b717dceccfb21f9d0c Mon Sep 17 00:00:00 2001 From: "Felix S. Klock II" Date: Wed, 26 Jan 2022 14:44:32 -0500 Subject: [PATCH 1620/2516] 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/doc/rustc-dev-guide/src/git.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index e9588fd5977f0..6af774ca803b2 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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 2cf5bba9e3b74db398f48e7be02e1ef1baab1529 Mon Sep 17 00:00:00 2001 From: Manish Goregaokar Date: Fri, 4 Feb 2022 22:03:17 -0800 Subject: [PATCH 1621/2516] mention test folders for cfg(bootstrap) (#1294) --- src/doc/rustc-dev-guide/src/stabilization_guide.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 60d333a371c7a..850168705daeb 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 4fed2149d627b0a35fbc4bafe880612fbc665670 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 11 Feb 2022 05:34:23 +0900 Subject: [PATCH 1622/2516] Triage some date references (#1293) --- src/doc/rustc-dev-guide/src/crates-io.md | 4 ++-- .../src/diagnostics/diagnostic-items.md | 2 +- src/doc/rustc-dev-guide/src/diagnostics/lintstore.md | 10 +++++----- src/doc/rustc-dev-guide/src/git.md | 4 ++-- src/doc/rustc-dev-guide/src/tests/compiletest.md | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/crates-io.md b/src/doc/rustc-dev-guide/src/crates-io.md index 62143defa6e2f..896f2697ce5d6 100644 --- a/src/doc/rustc-dev-guide/src/crates-io.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md index b5cba717fc796..61e3c3aec40e2 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index b544d2b6d62ad..489771dac4f18 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index 6af774ca803b2..d5c37f82dfa77 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/compiletest.md b/src/doc/rustc-dev-guide/src/tests/compiletest.md index b54bdfcfd8566..503b95f19f156 100644 --- a/src/doc/rustc-dev-guide/src/tests/compiletest.md +++ b/src/doc/rustc-dev-guide/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 056e4e70e302a33c4aee1b1b38c8633824b9af5e 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 1623/2516] Correction, building stage3 compiler (#1298) --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 93ebb487e39a3..3fd4ef19115c5 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 30386f52c1b24e86fd40579140989e4542671104 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 1624/2516] Link to The Rust Performance Book (#1300) --- src/doc/rustc-dev-guide/src/getting-started.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/getting-started.md b/src/doc/rustc-dev-guide/src/getting-started.md index a5e67456ee739..b4dc11a68e8a6 100644 --- a/src/doc/rustc-dev-guide/src/getting-started.md +++ b/src/doc/rustc-dev-guide/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 2d33dbd197a086f4c2fdf76e0221cee390b2c164 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 1625/2516] Edit "Queries" chapter (#1301) Makes various edits for clarity, style, readability, and formatting. Co-authored-by: Noah Lev --- src/doc/rustc-dev-guide/src/query.md | 85 +++++++++++++++------------- 1 file changed, 45 insertions(+), 40 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 7195687919d60..9c8cbd9b9979d 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 e35e01062daf9227daf550a693912208aacbfad8 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 1626/2516] Fix link --- src/doc/rustc-dev-guide/src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 9c8cbd9b9979d..ff2796a2d1cab 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 ae8ef405dd6eb32f9d664c578f49a3d3d89f8cb0 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Thu, 17 Feb 2022 13:48:36 -0800 Subject: [PATCH 1627/2516] Fix heading levels in the query chapter (#1305) This should fix the incorrect TOC rendering in #1303. --- src/doc/rustc-dev-guide/src/query.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index ff2796a2d1cab..6e02bfc7bfa23 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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 acf7323f9ea0c018687dbfa658a4e39c4564717f 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 1628/2516] Edit glossary (#1302) Add back-ticks to a few terms that appear in code. Clarify that `tcx` is a standard. --- src/doc/rustc-dev-guide/src/appendix/glossary.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 4eba27fce2c2e..375db493c8e58 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/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 e0b7531888ce1a89e3a1a653c2bdb444832c3bb9 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 1629/2516] Fix `Ty` link (#1308) --- src/doc/rustc-dev-guide/src/appendix/code-index.md | 2 +- src/doc/rustc-dev-guide/src/overview.md | 2 +- src/doc/rustc-dev-guide/src/ty.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/appendix/code-index.md b/src/doc/rustc-dev-guide/src/appendix/code-index.md index 68d12be37bf79..f645c0118fc61 100644 --- a/src/doc/rustc-dev-guide/src/appendix/code-index.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 02e56ca03a666..c77fd6cf6ae2d 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index 95141b6f28851..5749cdcd34bbd 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/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 0f1de50c2e46c5ceed75a2a4f51b361fc506fad7 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sun, 20 Feb 2022 07:00:41 -0800 Subject: [PATCH 1630/2516] symbol-mangling-version has been stabilized --- src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index cb3be57ac070a..3337f6ad80efd 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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 bf76c05b7fccfdb1d8ce10a162dc097ea6bf6c66 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sun, 20 Feb 2022 07:09:56 -0800 Subject: [PATCH 1631/2516] 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/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 3337f6ad80efd..ea4bdfca6d96a 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profile-guided-optimization.md b/src/doc/rustc-dev-guide/src/profile-guided-optimization.md index bf7615878cad3..db2624e92f7cd 100644 --- a/src/doc/rustc-dev-guide/src/profile-guided-optimization.md +++ b/src/doc/rustc-dev-guide/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 d794d74251643182a56730c96532a3c88d74455f 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 1632/2516] Typo (#1313) --- src/doc/rustc-dev-guide/src/mir/dataflow.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index 0e626d97c6577..6fe8d6aa5a7bc 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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 e16df874b0a50f57b4713b12a19fed4739bf720e 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 1633/2516] Fix typo (#1315) --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 48f501a02392b..b6ba3000e5d81 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 02096e23e377b320a0afd8ac61019044e7ac7b06 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 24 Feb 2022 20:40:58 -0800 Subject: [PATCH 1634/2516] Add known-bug header. (#1311) --- src/doc/rustc-dev-guide/src/tests/headers.md | 2 ++ src/doc/rustc-dev-guide/src/tests/ui.md | 15 +++++++++++++++ 2 files changed, 17 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/tests/headers.md b/src/doc/rustc-dev-guide/src/tests/headers.md index adc5fa6c9b68e..bdbe0a14ead18 100644 --- a/src/doc/rustc-dev-guide/src/tests/headers.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/ui.md b/src/doc/rustc-dev-guide/src/tests/ui.md index a8e8d3b7209a2..c1c10514186f9 100644 --- a/src/doc/rustc-dev-guide/src/tests/ui.md +++ b/src/doc/rustc-dev-guide/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 211231eacfcb9ffe7e07c8d2f6b19e2188ea3180 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sun, 27 Feb 2022 20:26:00 -0800 Subject: [PATCH 1635/2516] cargo timings has been stabilized (#1319) Co-authored-by: pierwill <19642016+pierwill@users.noreply.github.com> --- src/doc/rustc-dev-guide/src/profiling.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index 0d333f7be88d4..711248f19e704 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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 db07376c686316ea6cbc1e61d0f1f0fe89d1cf78 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 1636/2516] Add architecture suggestion for Apple silicon (#1320) --- src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 3fd4ef19115c5..dd997c81415de 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 7a93737e8a752f688ccd840f67132385d938c1d6 Mon Sep 17 00:00:00 2001 From: Chayim Refael Friedman Date: Wed, 2 Mar 2022 04:27:13 +0200 Subject: [PATCH 1637/2516] Fix incorrectly escaped backtick --- src/doc/rustc-dev-guide/src/diagnostics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 20dbefd7b0690..3671a0eccff54 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 1916c191c311215ed2b3398c1dd0c2d2fe620d1a Mon Sep 17 00:00:00 2001 From: Guillaume Gomez Date: Wed, 9 Mar 2022 14:36:37 +0100 Subject: [PATCH 1638/2516] Add missing rustdoc tests explanations --- src/doc/rustc-dev-guide/src/tests/compiletest.md | 13 +++++++------ src/doc/rustc-dev-guide/src/tests/intro.md | 2 ++ 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/tests/compiletest.md b/src/doc/rustc-dev-guide/src/tests/compiletest.md index 503b95f19f156..7e147c9ceb7ca 100644 --- a/src/doc/rustc-dev-guide/src/tests/compiletest.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/intro.md b/src/doc/rustc-dev-guide/src/tests/intro.md index 65facccbaad1c..92f6cb6642658 100644 --- a/src/doc/rustc-dev-guide/src/tests/intro.md +++ b/src/doc/rustc-dev-guide/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 af97ff48c7fca7bf2067d5e5d399a8e6dda1e1e7 Mon Sep 17 00:00:00 2001 From: skippy10110 Date: Sat, 12 Mar 2022 19:04:16 -0400 Subject: [PATCH 1639/2516] 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/doc/rustc-dev-guide/src/building/prerequisites.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/prerequisites.md b/src/doc/rustc-dev-guide/src/building/prerequisites.md index cfe4c7738386b..a5ab23d9168f7 100644 --- a/src/doc/rustc-dev-guide/src/building/prerequisites.md +++ b/src/doc/rustc-dev-guide/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 ab445871d680343164735a9137416d1053c687ec Mon Sep 17 00:00:00 2001 From: lcnr Date: Tue, 22 Mar 2022 14:34:21 +0100 Subject: [PATCH 1640/2516] update section for type system constants (#1329) * update section for type system constants * Update src/constants.md --- src/doc/rustc-dev-guide/src/constants.md | 49 ++++++++++++++---------- 1 file changed, 29 insertions(+), 20 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/constants.md b/src/doc/rustc-dev-guide/src/constants.md index 30c0da736f931..0b3becec3ac84 100644 --- a/src/doc/rustc-dev-guide/src/constants.md +++ b/src/doc/rustc-dev-guide/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 86e586bc74a6ada2e33d85be2b8d8975364d6c1b Mon Sep 17 00:00:00 2001 From: xFrednet Date: Fri, 1 Apr 2022 19:55:51 +0200 Subject: [PATCH 1641/2516] Add example how lints can be feature gated --- src/doc/rustc-dev-guide/src/diagnostics.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 3671a0eccff54..b6752042852c6 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 690de884e2e7124f0cb4a0f241ff2cb6b5b5e239 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 1642/2516] Update miri.md: correct a minor typo (#1334) --- src/doc/rustc-dev-guide/src/miri.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/miri.md b/src/doc/rustc-dev-guide/src/miri.md index dd54f6548399b..c5de358d209f0 100644 --- a/src/doc/rustc-dev-guide/src/miri.md +++ b/src/doc/rustc-dev-guide/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 21fb9308bbd63484e246297c8f815d81e86c4ce7 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Sat, 9 Apr 2022 01:31:23 -0700 Subject: [PATCH 1643/2516] r-a: Use `python3 x.py` instead of `./x.py` (#1335) --- src/doc/rustc-dev-guide/src/building/suggested.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 14e0410ded1b5..a6ff65db3c331 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 ede045c69ddc588bc60c01757e514aa2088a126f Mon Sep 17 00:00:00 2001 From: Ujjawal Date: Mon, 11 Apr 2022 19:18:30 +0530 Subject: [PATCH 1644/2516] Update examples with 1.61.0-nightly (latest version) (#1330) Co-authored-by: Ujjawal Kumar --- src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs index 29fa24784ffcf..7177a286892ff 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs index d1b42658e1c0f..c25695dd020e3 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs index cbf48c9ceba71..c942ac3244286 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs +++ b/src/doc/rustc-dev-guide/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 47d15af17bac867a3206c121565f9ebfe7a29689 Mon Sep 17 00:00:00 2001 From: Ivor Wanders Date: Mon, 11 Apr 2022 09:51:22 -0400 Subject: [PATCH 1645/2516] Consolidate crates.io convention section (#1326) --- src/doc/rustc-dev-guide/src/conventions.md | 6 ++---- src/doc/rustc-dev-guide/src/crates-io.md | 2 +- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 16828c49677e3..1dac0e0ecfc99 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/crates-io.md b/src/doc/rustc-dev-guide/src/crates-io.md index 896f2697ce5d6..8c8fd0c384b73 100644 --- a/src/doc/rustc-dev-guide/src/crates-io.md +++ b/src/doc/rustc-dev-guide/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 6ef3617c8e8b826727ef068237d5afd786c85818 Mon Sep 17 00:00:00 2001 From: Matthew Woodcraft Date: Mon, 11 Apr 2022 15:29:48 +0100 Subject: [PATCH 1646/2516] method-lookup.md improvements (#1296) --- src/doc/rustc-dev-guide/src/method-lookup.md | 25 ++++++++++---------- 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/method-lookup.md b/src/doc/rustc-dev-guide/src/method-lookup.md index 250eea034f1dd..8eb8ec5ce0923 100644 --- a/src/doc/rustc-dev-guide/src/method-lookup.md +++ b/src/doc/rustc-dev-guide/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 0fb43fd62812baa624bd96043cee64bf1edf3243 Mon Sep 17 00:00:00 2001 From: David Wood Date: Thu, 14 Apr 2022 13:57:32 +0800 Subject: [PATCH 1647/2516] sessiondiagnostic: translation (#1333) --- .../src/diagnostics/sessiondiagnostic.md | 252 +++++++++++++----- 1 file changed, 181 insertions(+), 71 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md b/src/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md index 4583e6d3dc953..e82d5629d52ff 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md +++ b/src/doc/rustc-dev-guide/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 3f26575287a29200cbf4273f713c62f905dd7490 Mon Sep 17 00:00:00 2001 From: Eric Holk Date: Thu, 14 Apr 2022 03:44:36 -0700 Subject: [PATCH 1648/2516] Minor type fix (#1337) --- .../borrow_check/region_inference/placeholders_and_universes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md index 967aa0d336dbb..91c8c45261191 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/doc/rustc-dev-guide/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 d2907204973f4b6767abf55c96ce1a2848887e1b Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Thu, 14 Apr 2022 12:46:54 +0200 Subject: [PATCH 1649/2516] Fix typo serious->series (#1336) --- src/doc/rustc-dev-guide/src/traits/caching.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/traits/caching.md b/src/doc/rustc-dev-guide/src/traits/caching.md index c963aafc4a90b..54bd0704a1c1e 100644 --- a/src/doc/rustc-dev-guide/src/traits/caching.md +++ b/src/doc/rustc-dev-guide/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 5c6e8394135565c6de4439ff1794d94c0d2c0d62 Mon Sep 17 00:00:00 2001 From: scottmcm Date: Thu, 14 Apr 2022 11:10:34 +0000 Subject: [PATCH 1650/2516] 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/doc/rustc-dev-guide/src/stabilization_guide.md b/src/doc/rustc-dev-guide/src/stabilization_guide.md index 850168705daeb..454cd0f27b96d 100644 --- a/src/doc/rustc-dev-guide/src/stabilization_guide.md +++ b/src/doc/rustc-dev-guide/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 89579a8037040055ef6d169a16bc2a670033e9df Mon Sep 17 00:00:00 2001 From: Felix S Klock II Date: Thu, 14 Apr 2022 07:17:36 -0400 Subject: [PATCH 1651/2516] Extend debugging llvm section (#1290) --- .../rustc-dev-guide/src/backend/debugging.md | 111 +++++++++++++++--- 1 file changed, 94 insertions(+), 17 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/backend/debugging.md b/src/doc/rustc-dev-guide/src/backend/debugging.md index 6736601676506..791a61fbe7107 100644 --- a/src/doc/rustc-dev-guide/src/backend/debugging.md +++ b/src/doc/rustc-dev-guide/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 4a20975d076bf8aab3004b1d3b3089ae2a3a3f8a Mon Sep 17 00:00:00 2001 From: printfn Date: Wed, 20 Apr 2022 11:57:49 +0200 Subject: [PATCH 1652/2516] Fix a small typo (#1343) --- src/doc/rustc-dev-guide/src/part-5-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/part-5-intro.md b/src/doc/rustc-dev-guide/src/part-5-intro.md index 78e6fa2e9bc32..4b7c25797c1a3 100644 --- a/src/doc/rustc-dev-guide/src/part-5-intro.md +++ b/src/doc/rustc-dev-guide/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 d265ea3c8f6f88fd3b2c40fdd4c639720ec4eff9 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 15 Apr 2022 16:57:37 +0900 Subject: [PATCH 1653/2516] Update some date refs --- src/doc/rustc-dev-guide/src/contributing.md | 8 ++++---- src/doc/rustc-dev-guide/src/conventions.md | 2 +- src/doc/rustc-dev-guide/src/salsa.md | 2 +- src/doc/rustc-dev-guide/src/thir.md | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 0c6b15da3eef8..3fe0948cc09ae 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/conventions.md b/src/doc/rustc-dev-guide/src/conventions.md index 1dac0e0ecfc99..15d1253776354 100644 --- a/src/doc/rustc-dev-guide/src/conventions.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index a6a6b97069173..d9190f64628d5 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/thir.md b/src/doc/rustc-dev-guide/src/thir.md index 95009e5529b24..4f8e6512c21b3 100644 --- a/src/doc/rustc-dev-guide/src/thir.md +++ b/src/doc/rustc-dev-guide/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 8c6f4f41aba69fc71391f225aa268e5194048d67 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 1654/2516] Edit "What the compiler does to your code" (#1306) * Edit overview.md * Fix lexer crate * Edit wording Co-authored-by: pierwill --- src/doc/rustc-dev-guide/src/overview.md | 216 ++++++++++++++---------- 1 file changed, 124 insertions(+), 92 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index c77fd6cf6ae2d..e7ea11e37fff8 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 f320bf72a114e2f80d78e5168b708794a185b853 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 3 May 2022 09:28:26 -0500 Subject: [PATCH 1655/2516] 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/doc/rustc-dev-guide/src/SUMMARY.md | 1 + .../src/diagnostics/error-guaranteed.md | 37 +++++++++++++++++++ 2 files changed, 38 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/diagnostics/error-guaranteed.md diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 3189b93644629..e74ef5e4e9cb2 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/error-guaranteed.md b/src/doc/rustc-dev-guide/src/diagnostics/error-guaranteed.md new file mode 100644 index 0000000000000..5a9b7f33546fd --- /dev/null +++ b/src/doc/rustc-dev-guide/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 3ddc6e2f85017321250dcebeee533546cf36c826 Mon Sep 17 00:00:00 2001 From: Ali MJ Al-Nasrawy Date: Sat, 7 May 2022 03:58:20 +0300 Subject: [PATCH 1656/2516] correct type of SubstsRef (#1347) --- src/doc/rustc-dev-guide/src/generics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/generics.md b/src/doc/rustc-dev-guide/src/generics.md index c7a0be09355df..13549b2fbe885 100644 --- a/src/doc/rustc-dev-guide/src/generics.md +++ b/src/doc/rustc-dev-guide/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 e0bb752dfe235386a2579ade9fc7c32b9ee10c44 Mon Sep 17 00:00:00 2001 From: Yutaro Ohno Date: Mon, 9 May 2022 09:17:51 +0900 Subject: [PATCH 1657/2516] Fix format (#1349) --- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index b6ba3000e5d81..c61afbcd970a1 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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 4ca8504912e039b6481e981368ad1e5548d032ab Mon Sep 17 00:00:00 2001 From: lcnr Date: Mon, 9 May 2022 02:19:43 +0200 Subject: [PATCH 1658/2516] mention `WithOptConstParam` (#1346) --- src/doc/rustc-dev-guide/src/constants.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/constants.md b/src/doc/rustc-dev-guide/src/constants.md index 0b3becec3ac84..4f1027b989a84 100644 --- a/src/doc/rustc-dev-guide/src/constants.md +++ b/src/doc/rustc-dev-guide/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 5208de7e80114cf0f53db51d73ae70529b73a12e Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 9 May 2022 22:47:50 +0900 Subject: [PATCH 1659/2516] Update date references on parallel-rustc (#1348) --- src/doc/rustc-dev-guide/src/parallel-rustc.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index 2ee302d244cf4..1714a56ca6cc1 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 5a1aeb7a797e0a5f5531aa6a87c2bd99b49004e5 Mon Sep 17 00:00:00 2001 From: Soroush Zare Date: Tue, 10 May 2022 17:15:31 +0430 Subject: [PATCH 1660/2516] Update overview.md (#1351) Fix minor typo --- src/doc/rustc-dev-guide/src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index e7ea11e37fff8..a3c2258e88973 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 76114ad4372963120484918e1177283d6dd37123 Mon Sep 17 00:00:00 2001 From: Jacob Pratt Date: Thu, 12 May 2022 00:53:26 -0400 Subject: [PATCH 1661/2516] Update docs for deprecated attribute (#1338) --- src/doc/rustc-dev-guide/src/stability.md | 33 +++++++++++------------- 1 file changed, 15 insertions(+), 18 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/stability.md b/src/doc/rustc-dev-guide/src/stability.md index 51d849200cde5..3469ce2baac5d 100644 --- a/src/doc/rustc-dev-guide/src/stability.md +++ b/src/doc/rustc-dev-guide/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 ac519c71d418faeafe51cb280bb13fe46595bfd0 Mon Sep 17 00:00:00 2001 From: Waffle Maybe Date: Thu, 12 May 2022 08:56:14 +0400 Subject: [PATCH 1662/2516] Fix configuration names for vscode/r-a (#1352) --- src/doc/rustc-dev-guide/src/building/suggested.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index a6ff65db3c331..f54ee15f80550 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 11b6e86ce7c0253b64efc240d555e4a36209b06f Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 16 May 2022 23:36:40 +0900 Subject: [PATCH 1665/2516] Replace a broken YouTube link (#1295) --- src/doc/rustc-dev-guide/src/mir/dataflow.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index 6fe8d6aa5a7bc..7fe807d37c1f4 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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 ccde9c81b77959d51422d413c9c57bc06233dfd3 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 17 May 2022 07:54:45 +0900 Subject: [PATCH 1666/2516] Update some links and docs (#1340) --- .../src/borrow_check/region_inference.md | 7 +++--- .../rustc-dev-guide/src/building/suggested.md | 8 +++---- src/doc/rustc-dev-guide/src/contributing.md | 6 ++--- src/doc/rustc-dev-guide/src/git.md | 2 +- .../rustc-dev-guide/src/macro-expansion.md | 24 ++++++++++--------- src/doc/rustc-dev-guide/src/query.md | 2 +- src/doc/rustc-dev-guide/src/tests/running.md | 2 +- 7 files changed, 26 insertions(+), 25 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md b/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md index cfb32bf07f7aa..330c079b96016 100644 --- a/src/doc/rustc-dev-guide/src/borrow_check/region_inference.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index f54ee15f80550..196ff5fe8b87a 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 3fe0948cc09ae..48d8b2d15792c 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md index d5c37f82dfa77..e55dbf858e2ed 100644 --- a/src/doc/rustc-dev-guide/src/git.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index e3b5a27e6b235..840bfabe83752 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 6e02bfc7bfa23..95e570dfc7b76 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/tests/running.md b/src/doc/rustc-dev-guide/src/tests/running.md index 2e823c0edda5b..6e15cb191f42d 100644 --- a/src/doc/rustc-dev-guide/src/tests/running.md +++ b/src/doc/rustc-dev-guide/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 f1ad54fe583bafaf83a9a32fdfcb64eaa966c24d Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 20 May 2022 14:37:01 +0200 Subject: [PATCH 1667/2516] make sentence more simple (#1353) --- src/doc/rustc-dev-guide/src/mir/dataflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/dataflow.md b/src/doc/rustc-dev-guide/src/mir/dataflow.md index 7fe807d37c1f4..ce4a86a239d24 100644 --- a/src/doc/rustc-dev-guide/src/mir/dataflow.md +++ b/src/doc/rustc-dev-guide/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 5fd3d1dde7c7e90fdc1345b4495f56c373818ffa Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 20 May 2022 20:53:51 -0700 Subject: [PATCH 1668/2516] Add note about patching dependencies and warnings. (#1354) --- src/doc/rustc-dev-guide/src/building/new-target.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index b5fc2cb0ad261..f216ed0b767bc 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/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 c4041d22ab11f7864ebeb68dca434d6cd40f18e0 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 25 May 2022 08:01:26 +0900 Subject: [PATCH 1669/2516] 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. --- src/doc/rustc-dev-guide/book.toml | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 336e5a3695c37..8b9f57594441c 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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 39497c417142da87298c4f29904f5fcfd77d560b Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 24 May 2022 18:49:07 +0900 Subject: [PATCH 1670/2516] 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/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index f81e02d28fa79..dc196e490ff74 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/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 bdaf7e6bd62a8bc619b13cf050089a1fe763a1ca Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 21 May 2022 17:05:08 +0900 Subject: [PATCH 1671/2516] Cleanup rustdoc-internals --- .../rustc-dev-guide/src/rustdoc-internals.md | 33 +++++-------------- 1 file changed, 8 insertions(+), 25 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/rustdoc-internals.md b/src/doc/rustc-dev-guide/src/rustdoc-internals.md index ccf0fcc5feb50..1050c259b1aea 100644 --- a/src/doc/rustc-dev-guide/src/rustdoc-internals.md +++ b/src/doc/rustc-dev-guide/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 637f3f2af8524b91f7c159c455166496c51d1515 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 28 May 2022 12:24:55 +0900 Subject: [PATCH 1672/2516] Triage some date references related to traits --- src/doc/rustc-dev-guide/src/traits/chalk.md | 11 ++++++----- src/doc/rustc-dev-guide/src/traits/resolution.md | 2 +- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/traits/chalk.md b/src/doc/rustc-dev-guide/src/traits/chalk.md index db3c19a386091..d4045c460cd12 100644 --- a/src/doc/rustc-dev-guide/src/traits/chalk.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md index 70b53e9105748..c22ee6de6196a 100644 --- a/src/doc/rustc-dev-guide/src/traits/resolution.md +++ b/src/doc/rustc-dev-guide/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 93771d84e0f5113a3ff8418541e34eca05858a8f Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 2 May 2022 08:19:20 +0900 Subject: [PATCH 1673/2516] Update rustc-driver related examples --- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md | 2 +- 6 files changed, 19 insertions(+), 16 deletions(-) diff --git a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs index 7177a286892ff..8a5d880fab2e4 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs index c25695dd020e3..3bb0d5450415c 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs index c942ac3244286..a0110f82d92be 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md b/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md index fa5ce0750efd5..b3f18a67e59ca 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md b/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md index 7cb53187b25f6..1ec9c1c324d74 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver.md b/src/doc/rustc-dev-guide/src/rustc-driver.md index 2cffba42c878e..7250c852c58aa 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver.md +++ b/src/doc/rustc-dev-guide/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 46d48d8d72cfd28e259535762c501bdca285214b 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 1674/2516] Clarify cargo fallback behavior for rustup link (#1273) --- .../rustc-dev-guide/src/building/how-to-build-and-run.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index dd997c81415de..9ef43e341ceab 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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 8cc4c20c1dc316fec00bfbef0f23939130e44426 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 1675/2516] 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> --- .../rustc-dev-guide/ci/date-check/Cargo.lock | 34 ++++++------------- 1 file changed, 10 insertions(+), 24 deletions(-) diff --git a/src/doc/rustc-dev-guide/ci/date-check/Cargo.lock b/src/doc/rustc-dev-guide/ci/date-check/Cargo.lock index 296a132d43e1d..00fa3def81491 100644 --- a/src/doc/rustc-dev-guide/ci/date-check/Cargo.lock +++ b/src/doc/rustc-dev-guide/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 370fe5964b709cd92fa5eaf2abf5cb25c050567b Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Tue, 7 Jun 2022 01:42:07 +0200 Subject: [PATCH 1676/2516] improve rustc_interface examples a little (#1362) --- .../examples/rustc-driver-example.rs | 25 +++++++++++-------- .../rustc-driver-getting-diagnostics.rs | 11 +++++--- .../rustc-driver-interacting-with-the-ast.rs | 16 +++++++----- .../src/rustc-driver-getting-diagnostics.md | 2 +- .../rustc-driver-interacting-with-the-ast.md | 2 +- 5 files changed, 35 insertions(+), 21 deletions(-) diff --git a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs index 8a5d880fab2e4..4203fe96a0bd2 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-example.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs index 3bb0d5450415c..1d3a4034e4d00 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-getting-diagnostics.rs +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs b/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs index a0110f82d92be..231994a97d146 100644 --- a/src/doc/rustc-dev-guide/examples/rustc-driver-interacting-with-the-ast.rs +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md b/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md index b3f18a67e59ca..a7251c2f0e776 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md b/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md index 1ec9c1c324d74..86732de18770b 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md +++ b/src/doc/rustc-dev-guide/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 a335dd2d31d1082529df0fde38f07efd291ced1a Mon Sep 17 00:00:00 2001 From: Jonas Schievink Date: Wed, 8 Jun 2022 01:06:32 +0200 Subject: [PATCH 1677/2516] Make build scripts and proc macros work with the suggested rust-analyzer config (#1365) --- src/doc/rustc-dev-guide/src/building/suggested.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 196ff5fe8b87a..6c0b7135e934d 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/error-guaranteed.md b/src/doc/rustc-dev-guide/src/diagnostics/error-guaranteed.md index 5a9b7f33546fd..d92ba62abb3d6 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/error-guaranteed.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/lintstore.md b/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md index 489771dac4f18..39007f8d1d2a4 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/lintstore.md +++ b/src/doc/rustc-dev-guide/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 94eeef6ff05cd31a26bbe450512fbe2959b889d6 Mon Sep 17 00:00:00 2001 From: David Wood Date: Mon, 6 Jun 2022 14:07:55 +0100 Subject: [PATCH 1683/2516] 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 --- src/doc/rustc-dev-guide/book.toml | 1 + src/doc/rustc-dev-guide/src/SUMMARY.md | 7 +- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/diagnostic-structs.md delete mode 100644 src/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md create mode 100644 src/doc/rustc-dev-guide/src/diagnostics/translation.md diff --git a/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index 8b9f57594441c..c4450cf0c33a4 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index e74ef5e4e9cb2..3029762963059 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index b6752042852c6..7ef33d38e6f74 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md index af11eb9ea2782..0031ba28406a2 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-items.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/diagnostic-structs.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-structs.md new file mode 100644 index 0000000000000..cab9b0c2f9867 --- /dev/null +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md b/src/doc/rustc-dev-guide/src/diagnostics/sessiondiagnostic.md deleted file mode 100644 index e82d5629d52ff..0000000000000 --- a/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/diagnostics/translation.md b/src/doc/rustc-dev-guide/src/diagnostics/translation.md new file mode 100644 index 0000000000000..5c078ffb3234c --- /dev/null +++ b/src/doc/rustc-dev-guide/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 46a3e18d38d5b8df78035982635ba327b834745a Mon Sep 17 00:00:00 2001 From: Edwin Date: Sat, 18 Jun 2022 04:31:49 +0100 Subject: [PATCH 1684/2516] Add an "is" and rearange "We next" to "Next, we" (#1369) --- src/doc/rustc-dev-guide/src/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index a3c2258e88973..ea4b3ca046bae 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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 16824a22e744b9e53b0d55f9f72147c2aa037590 Mon Sep 17 00:00:00 2001 From: Omer Tuchfeld Date: Sat, 18 Jun 2022 12:42:08 +0200 Subject: [PATCH 1685/2516] Fix small `src/diagnostics.md` typo (#1370) --- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 7ef33d38e6f74..dbf5cf99eb9e1 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 3252a2c0e73da824cae9a456514fcabc89b3f8da Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Tue, 21 Jun 2022 06:26:19 +0200 Subject: [PATCH 1686/2516] make clear that other versions can work (#1373) --- src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md b/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md index a7251c2f0e776..327415e5aaeac 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-getting-diagnostics.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md b/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md index 86732de18770b..d70264fe4f20c 100644 --- a/src/doc/rustc-dev-guide/src/rustc-driver-interacting-with-the-ast.md +++ b/src/doc/rustc-dev-guide/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 852dc6381dd3ec53a9b82cc09aba96d32ceef8c1 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Tue, 21 Jun 2022 11:45:30 +0200 Subject: [PATCH 1687/2516] small improves (#1371) Co-authored-by: Yuki Okushi --- src/doc/rustc-dev-guide/src/diagnostics.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index dbf5cf99eb9e1..0f0bfd895a403 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/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 e2666525e5f781a28f416d628bd10323bdf47129 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Tue, 21 Jun 2022 15:25:34 +0200 Subject: [PATCH 1688/2516] not obvious what Ex is, so rather get rid (#1372) --- src/doc/rustc-dev-guide/src/SUMMARY.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 3029762963059..e25eb284ea163 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/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 d8e5995983ac0c3320fee2ef1c95ed67e6bfa472 Mon Sep 17 00:00:00 2001 From: Alcaro Date: Sun, 26 Jun 2022 14:02:21 +0200 Subject: [PATCH 1689/2516] humorust: Forbid pineapple on pizza (#1374) --- src/doc/rustc-dev-guide/src/appendix/humorust.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/doc/rustc-dev-guide/src/appendix/humorust.md b/src/doc/rustc-dev-guide/src/appendix/humorust.md index c502527d5b523..bc8255439ece1 100644 --- a/src/doc/rustc-dev-guide/src/appendix/humorust.md +++ b/src/doc/rustc-dev-guide/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 9ab4469c652ad55bf55da9e43c215aa68a9513e9 Mon Sep 17 00:00:00 2001 From: EdwinRy Date: Mon, 27 Jun 2022 01:29:25 +0100 Subject: [PATCH 1690/2516] Few readability fixes --- src/doc/rustc-dev-guide/src/salsa.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index d9190f64628d5..e0303127e45b1 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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 7bf03d61bf21941f42e6db2738ce220e5d9f12d3 Mon Sep 17 00:00:00 2001 From: David Wood Date: Tue, 28 Jun 2022 17:17:15 +0100 Subject: [PATCH 1691/2516] 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/doc/rustc-dev-guide/src/diagnostics/diagnostic-structs.md b/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-structs.md index cab9b0c2f9867..f28350e03388b 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics/diagnostic-structs.md +++ b/src/doc/rustc-dev-guide/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 3cb910acead67e4979af832aa5ccd2382297db67 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Fri, 1 Jul 2022 11:35:13 -0400 Subject: [PATCH 1692/2516] leave formatOnSave to the user (#1380) --- src/doc/rustc-dev-guide/src/building/suggested.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/suggested.md b/src/doc/rustc-dev-guide/src/building/suggested.md index 6c0b7135e934d..df79aed79f7f7 100644 --- a/src/doc/rustc-dev-guide/src/building/suggested.md +++ b/src/doc/rustc-dev-guide/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 0506cdb667038d638033f0a20752af00d047eab0 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Thu, 14 Jul 2022 22:41:12 +0200 Subject: [PATCH 1704/2516] update date reference on MIR inliner cc #1379 --- src/doc/rustc-dev-guide/src/profiling.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index 711248f19e704..e4148e68eb064 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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 950191c7c177928c728171483090da9155f2cc7d Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Fri, 15 Jul 2022 00:44:47 +0200 Subject: [PATCH 1705/2516] address review comment https://github.com/rust-lang/rustc-dev-guide/pull/1392#discussion_r921560851 --- src/doc/rustc-dev-guide/src/profiling.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/profiling.md b/src/doc/rustc-dev-guide/src/profiling.md index e4148e68eb064..ada497d88a282 100644 --- a/src/doc/rustc-dev-guide/src/profiling.md +++ b/src/doc/rustc-dev-guide/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 7e15874ff980b0498bc8cb5eb54770dc1aea21e8 Mon Sep 17 00:00:00 2001 From: 5225225 <5225225@mailbox.org> Date: Sat, 16 Jul 2022 11:27:44 +0100 Subject: [PATCH 1706/2516] Rename debugging_opts to unstable_opts, use link --- src/doc/rustc-dev-guide/src/mir/optimizations.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index add22c6fcf5f0..f81f1886409dd 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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 749034f4ffea34b78a1c302fe7f2bd048efc30f7 Mon Sep 17 00:00:00 2001 From: davidrusu Date: Sat, 16 Jul 2022 10:18:19 -0400 Subject: [PATCH 1707/2516] typo: monomorph docs --- src/doc/rustc-dev-guide/src/backend/monomorph.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index 7111c634a33e7..fe61bcb8a3d32 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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 39f4d88d48ac375b4f9f1c8e44a9b261b153646a Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 16 Jul 2022 23:45:36 +0200 Subject: [PATCH 1708/2516] fix some typos (#1398) --- src/doc/rustc-dev-guide/src/asm.md | 2 +- src/doc/rustc-dev-guide/src/backend/monomorph.md | 2 +- src/doc/rustc-dev-guide/src/building/bootstrapping.md | 2 +- src/doc/rustc-dev-guide/src/lang-items.md | 4 ++-- src/doc/rustc-dev-guide/src/salsa.md | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/asm.md b/src/doc/rustc-dev-guide/src/asm.md index 2c177164e937f..cd5430ffdaf6c 100644 --- a/src/doc/rustc-dev-guide/src/asm.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/monomorph.md b/src/doc/rustc-dev-guide/src/backend/monomorph.md index fe61bcb8a3d32..416151ca9b735 100644 --- a/src/doc/rustc-dev-guide/src/backend/monomorph.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/bootstrapping.md b/src/doc/rustc-dev-guide/src/building/bootstrapping.md index 31f9b61d69d69..fd54de20ce312 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/lang-items.md b/src/doc/rustc-dev-guide/src/lang-items.md index c5774c43ba42c..867c42144770e 100644 --- a/src/doc/rustc-dev-guide/src/lang-items.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/salsa.md b/src/doc/rustc-dev-guide/src/salsa.md index e0303127e45b1..afa01eda2dff0 100644 --- a/src/doc/rustc-dev-guide/src/salsa.md +++ b/src/doc/rustc-dev-guide/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 58a3a721b9ce5143deaa5aa8e7eaeb4dab14fe19 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 16 Jul 2022 12:38:55 +0200 Subject: [PATCH 1709/2516] 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/doc/rustc-dev-guide/src/contributing.md | 4 +- .../src/implementing_new_features.md | 4 +- .../rustc-dev-guide/src/macro-expansion.md | 2 +- .../rustc-dev-guide/src/mir/optimizations.md | 10 ++-- src/doc/rustc-dev-guide/src/overview.md | 50 +++++++++---------- src/doc/rustc-dev-guide/src/parallel-rustc.md | 14 +++--- 7 files changed, 43 insertions(+), 43 deletions(-) diff --git a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md b/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md index 39715bcd2f0bc..25344fb2176e9 100644 --- a/src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 7eeb0240b772a..fed14afbd33e5 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/implementing_new_features.md b/src/doc/rustc-dev-guide/src/implementing_new_features.md index 73a3543cd44b7..ef6ae61796211 100644 --- a/src/doc/rustc-dev-guide/src/implementing_new_features.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/macro-expansion.md b/src/doc/rustc-dev-guide/src/macro-expansion.md index 840bfabe83752..9b0f353d1a402 100644 --- a/src/doc/rustc-dev-guide/src/macro-expansion.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/mir/optimizations.md b/src/doc/rustc-dev-guide/src/mir/optimizations.md index f81f1886409dd..aa0a62fb0346c 100644 --- a/src/doc/rustc-dev-guide/src/mir/optimizations.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 09d87223d65e2..de6c88e7ee6dd 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/parallel-rustc.md b/src/doc/rustc-dev-guide/src/parallel-rustc.md index 1714a56ca6cc1..4aa13d781a306 100644 --- a/src/doc/rustc-dev-guide/src/parallel-rustc.md +++ b/src/doc/rustc-dev-guide/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 d1501b5cf159064d425846aa038cc233903c6524 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 7 Feb 2022 17:06:06 -0500 Subject: [PATCH 1710/2516] add mdbook-mermaid --- src/doc/rustc-dev-guide/.github/workflows/ci.yml | 4 +++- src/doc/rustc-dev-guide/book.toml | 4 ++++ src/doc/rustc-dev-guide/mermaid-init.js | 1 + src/doc/rustc-dev-guide/mermaid.min.js | 4 ++++ 4 files changed, 12 insertions(+), 1 deletion(-) create mode 100644 src/doc/rustc-dev-guide/mermaid-init.js create mode 100644 src/doc/rustc-dev-guide/mermaid.min.js diff --git a/src/doc/rustc-dev-guide/.github/workflows/ci.yml b/src/doc/rustc-dev-guide/.github/workflows/ci.yml index fed51378cd1d8..c571d408d8e60 100644 --- a/src/doc/rustc-dev-guide/.github/workflows/ci.yml +++ b/src/doc/rustc-dev-guide/.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/src/doc/rustc-dev-guide/book.toml b/src/doc/rustc-dev-guide/book.toml index c4450cf0c33a4..51dc8ecb053ef 100644 --- a/src/doc/rustc-dev-guide/book.toml +++ b/src/doc/rustc-dev-guide/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/src/doc/rustc-dev-guide/mermaid-init.js b/src/doc/rustc-dev-guide/mermaid-init.js new file mode 100644 index 0000000000000..313a6e8bc89d5 --- /dev/null +++ b/src/doc/rustc-dev-guide/mermaid-init.js @@ -0,0 +1 @@ +mermaid.initialize({startOnLoad:true}); diff --git a/src/doc/rustc-dev-guide/mermaid.min.js b/src/doc/rustc-dev-guide/mermaid.min.js new file mode 100644 index 0000000000000..d45942f362488 --- /dev/null +++ b/src/doc/rustc-dev-guide/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(/