fix(doctest): detect extern crate items in statement doctests
This partially reverts #91026, because rustdoc needs to detect the extern statements, even when they appear inside implicit `main()`. It does not entirely revert it, so the old bug is still fixed, by duplicating some of the logic from `parse_mod` instead of trying to use it directly.
Fixes#91134
By default, AST visitors visit expressions that appear in key-value attributes.
Those expressions should not be lowered to HIR, as they do not correspond to actually compiled code.
Since an attribute cannot produce meaningful HIR, just skip them altogether.
Rollup of 6 pull requests
Successful merges:
- #90856 (Suggestion to wrap inner types using 'allocator_api' in tuple)
- #91103 (Inhibit clicks on summary's children)
- #91137 (Give people a single link they can click in the contributing guide)
- #91140 (Split inline const to two feature gates and mark expression position inline const complete)
- #91148 (Use `derive_default_enum` in the compiler)
- #91153 (kernel_copy: avoid panic on unexpected OS error)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
kernel_copy: avoid panic on unexpected OS error
According to documentation, the listed errnos should only occur
if the `copy_file_range` call cannot be made at all, so the
assert be correct. However, since in practice file system
drivers (incl. FUSE etc.) can return any errno they want, we
should not panic here.
Fixes#91152
Split inline const to two feature gates and mark expression position inline const complete
This PR splits inline const in pattern position into its own `#![feature(inline_const_pat)]` feature gate, and make the usage in expression position complete.
I think I have resolved most outstanding issues related to `inline_const` with #89561 and other PRs. The only thing left that I am aware of is #90150 and the lack of lifetime checks when inline const is used in pattern position (FIXME in #89561). Implementation-wise when used in pattern position it has to be lowered during MIR building while in expression position it's evaluated only when monomorphizing (just like normal consts), so it makes some sense to separate it into two feature gates so one can progress without being blocked by another.
``@rustbot`` label: T-compiler F-inline_const
Give people a single link they can click in the contributing guide
Doc Jones mentioned that one of the things making it hard to get started
is that the amount of information is overwhelming, between the
dev-guide, contributing guide, and discussion platforms. This gives
people a single link they can click to ask for help.
cc ``@doc-jones`` - is this what you had in mind?
Inhibit clicks on summary's children
A byproduct of using `<details>` and `<summary>` to show/hide detailed documentation was that clicking any part of a method heading (or impl heading) would show or hide the documentation. This was not super noticeable because clicking a link inside the method heading would navigate to that link. But clicking any unlinked black text in a method heading would trigger the behavior.
That behavior was somewhat unexpected, and means that if you try to click a type name in a method heading, but miss by a few pixels, you get a confusing surprise.
This change inhibits that behavior by putting an event listener on most summaries that cancels the event unless the event target was the summary itself. In practice, that means it cancels the event unless the target was the "[+]" / "[-]", because the rest of the heading is wrapped inside a `<div>`, which is the target for anything that doesn't have a more specific target.
r? ``@Manishearth``
Suggestion to wrap inner types using 'allocator_api' in tuple
This PR provides a suggestion to wrap the inner types in tuple when being along with 'allocator_api'.
Closes https://github.com/rust-lang/rust/issues/83250
```rust
fn main() {
let _vec: Vec<u8, _> = vec![]; //~ ERROR use of unstable library feature 'allocator_api'
}
```
```diff
error[E0658]: use of unstable library feature 'allocator_api'
--> $DIR/suggest-vec-allocator-api.rs:2:23
|
LL | let _vec: Vec<u8, _> = vec![];
- | ^
+ | ----^
+ | |
+ | help: consider wrapping the inner types in tuple: `(u8, _)`
|
= note: see issue #32838 <https://github.com/rust-lang/rust/issues/32838> for more information
= help: add `#![feature(allocator_api)]` to the crate attributes to enable
```
Mark places as initialized when mutably borrowed
Fixes the example in #90752, but does not handle some corner cases involving raw pointers and unsafe. See [this comment](https://github.com/rust-lang/rust/issues/90752#issuecomment-965822895) for more information, or the second test.
Although I talked about both `MaybeUninitializedPlaces` and `MaybeInitializedPlaces` in #90752, this PR only changes the latter. That's because "maybe uninitialized" is the conservative choice, and marking them as definitely initialized (`!maybe_uninitialized`) when a mutable borrow is created could lead to problems if `addr_of_mut` to an uninitialized local is allowed. Additionally, places cannot become uninitialized via a mutable reference, so if a place is definitely initialized, taking a mutable reference to it should not change that.
I think it's correct to ignore interior mutability as nbdd0121 suggests below. Their analysis doesn't work inside of `core::cell`, which *does* have access to `UnsafeCell`'s field, but that won't be an issue unless we explicitly instantiate one with an `enum` within that module.
r? `@wesleywiser`
Avoid generating empty closures for fieldless enum variants
For many enums, this avoids generating lots of tiny stubs that need to be codegen'd and then inlined and removed by LLVM. perf shows this to be a fairly small, but significant, win on rustc bootstrap time -- with minimal impact on runtime performance (which is at times even positive).
According to documentation, the listed errnos should only occur
if the `copy_file_range` call cannot be made at all, so the
assert be correct. However, since in practice file system
drivers (incl. FUSE etc.) can return any errno they want, we
should not panic here.
Fixes#91152
Manually outline error on incremental_verify_ich
This reduces codegen for rustc_query_impl by 169k lines of LLVM IR, representing
a 1.2% improvement. This code should be fairly cold, so hopefully this has minimal
performance impact.
add codegen option for using LLVM stack smash protection
LLVM has built-in heuristics for adding stack canaries to functions. These
heuristics can be selected with LLVM function attributes. This PR adds a codegen
option `-C stack-protector={basic,strong,all}` which controls the use of these
attributes. This gives rustc the same stack smash protection support as clang
offers through options `-fstack-protector`, `-fstack-protector-strong`, and
`-fstack-protector-all`. The protection this can offer is demonstrated in
test/ui/abi/stack-protector.rs. This fills a gap in the current list of rustc
exploit mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html),
originally discussed in #15179.
Stack smash protection adds runtime overhead and is therefore still off by
default, but now users have the option to trade performance for security as they
see fit. An example use case is adding Rust code in an existing C/C++ code base
compiled with stack smash protection. Without the ability to add stack smash
protection to the Rust code, the code base artifacts could be exploitable in
ways not possible if the code base remained pure C/C++.
Stack smash protection support is present in LLVM for almost all the current
tier 1/tier 2 targets: see
test/assembly/stack-protector/stack-protector-target-support.rs. The one
exception is nvptx64-nvidia-cuda. This PR follows clang's example, and adds a
warning message printed if stack smash protection is used with this target (see
test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3
targets has not been checked.
Since the heuristics are applied at the LLVM level, the heuristics are expected
to add stack smash protection to a fraction of functions comparable to C/C++.
Some experiments demonstrating how Rust code is affected by the different
heuristics can be found in
test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is
potential for better heuristics using Rust-specific safety information. For
example it might be reasonable to skip stack smash protection in functions which
transitively only use safe Rust code, or which uses only a subset of functions
the user declares safe (such as anything under `std.*`). Such alternative
heuristics could be added at a later point.
LLVM also offers a "safestack" sanitizer as an alternative way to guard against
stack smashing (see #26612). This could possibly also be included as a
stack-protection heuristic. An alternative is to add it as a sanitizer (#39699).
This is what clang does: safestack is exposed with option
`-fsanitize=safe-stack`.
The options are only supported by the LLVM backend, but as with other codegen
options it is visible in the main codegen option help menu. The heuristic names
"basic", "strong", and "all" are hopefully sufficiently generic to be usable in
other backends as well.
Avoid documenting top-level private imports
PR #88447 aimed to make rustdoc's `--document-private-items` mode only document imports that are visible outside the importing module. Unfortunately, I inadvertently set things up so that imports at the crate top-level are always documented, regardless of their visibility. This behavior was unintended and is [not desirable](https://github.com/rust-lang/rust/issues/90865#issuecomment-971172649).
This PR treats top-level imports as never being visible outside their parent module. In practice, the only way a top-level import can be visible externally is if it's fully public, and there's a seperate check for that.
It's worth calling attention to the fact that this change means that `pub(crate)` imports will be visible in lower level modules, but not at the top-level. This is because, at the top level of the crate, `pub(crate)` means the same thing as `pub(self)`.
It turned out that there were existing tests checking for the only behavior, which I didn't notice at the time of my previous PR. I have updated them to check for the new behavior and substantially extended them to handle differences between the top-level module and lower level modules. I may have gone overboard, so please tell me if there's anything I should cut.
r? `@jyn514`
Fixes#90865.
This partially reverts #91026, because rustdoc needs to detect the extern statements,
even when they appear inside implicit `main()`. It does not entirely revert it,
so the old bug is still fixed, by duplicating some of the logic from `parse_mod`
instead of trying to use it directly.
Fixes#91134
Update cargo
7 commits in ad50d0d266213e0cc4f6e526a39d96faae9a3842..e1fb17631eb1b3665cdbe45b1c186111577ef512
2021-11-17 18:36:37 +0000 to 2021-11-22 16:53:06 +0000
- re-enable lto_build test on 32-bit MSVC (rust-lang/cargo#10110)
- Fix a couple issues with cyclic features and dev-dependencies (rust-lang/cargo#10103)
- Add --message-format for install command (rust-lang/cargo#10107)
- Update curl dependency, remove M1 macOS build error note (rust-lang/cargo#10106)
- Make clippy happy (rust-lang/cargo#10105)
- Give a hard error if `-Zrustdoc-scrape-examples` is missing a flag (rust-lang/cargo#10043)
- silly fix, pointer to the empty slice (rust-lang/cargo#10097)
Update books
## reference
3 commits in a01d151a7250a540a9cb7ccce5956f020c677c21..c0f222da23568477155991d391c9ce918e381351
2021-10-22 22:34:13 +0900 to 2021-11-22 10:30:57 -0800
- Byte literal and string syntax: add missing quote escapes (rust-lang/reference#1101)
- fix crate_name attribute description (rust-lang/reference#1109)
- Update list of types with magic Copy impls (rust-lang/reference#1104)
## book
19 commits in 5c5dbc5b196c9564422b3193264f3288d2a051ce..a5e0c5b2c5f9054be3b961aea2c7edfeea591de8
2021-11-09 19:30:43 -0500 to 2021-11-19 17:06:19 -0500
- Propagate edits to chapter 4 back
- Edits to the edits of chapter 4
- ch 4 from nostarch
- Fix install links
- Snapshot of chapter 10
- Fix quotes
- Add more explanation of Self in chapter 10. Fixesrust-lang/book#2222.
- We've defined the signatures, not behaviors. Fixesrust-lang/book#2917
- Remove 'most distinctive' claim. Fixesrust-lang/book#2861.
- Clarify that traits must be brought into scope to use their methods
- Explain why lifetimes are part of the function contract better
- Further edits to rust-lang/book#2895
- Clarify generic types in mixin
- Change 'either' to 'at least one of'. See rust-lang/book#2885
- Clarify explanation of lifetime annotations a bit
- Further edits to clarify code explanation
- Clarify the meaning of a sentence in ch10-03
- Clarify this code is demonstrating usage of the library from a binary. Fixesrust-lang/book#1445.
- Clarify generics in method definitions and impls. Fixesrust-lang/book#2679.
## rust-by-example
1 commits in e9d45342d7a6c1def4731f1782d87ea317ba30c3..43f82530210b83cf888282b207ed13d5893da9b2
2021-11-02 13:33:03 -0500 to 2021-11-21 22:31:50 -0300
- Update `Development dependencies` page. (rust-lang/rust-by-example#1478)
## rustc-dev-guide
7 commits in 196ef69aa68f2cef44f37566ee7db37daf00301b..a2fc9635029c04e692474965a6606f8e286d539a
2021-11-07 07:48:47 -0600 to 2021-11-18 13:31:13 -0500
- Describe drop elaboration (rust-lang/rustc-dev-guide#1240)
- Fix an invalid link on Diagnostic Items (rust-lang/rustc-dev-guide#1261)
- Fix broken links related to `rustc_borrowck` (rust-lang/rustc-dev-guide#1259)
- Unify `x.py` usage (rust-lang/rustc-dev-guide#1258)
- Spelling fixes
- Fix compare-mode documentation
- Fix broken link in "Bootstrapping"
## edition-guide
1 commits in 27f4a84d3852e9416cae5861254fa53a825c56bd..8e0ec8c77d8b28b86159fdee9d33a758225ecf9c
2021-11-08 10:13:20 -0500 to 2021-11-12 06:30:23 -0800
- Fix a broken link in the Disjoint Capture in Closure chapter (rust-lang/edition-guide#273)
## embedded-book
1 commits in 51739471276b1776dea27cf562b974ef07e24685..8c395bdd8073deb20ca67e1ed4b14a3a7e315a37
2021-10-17 16:48:42 +0000 to 2021-11-14 11:38:31 +0000
- added math chapter (rust-embedded/book#308)
Set color for <a> in a more straightforward way.
Previously, we set the default color for <a> tags to black, and then had an override with a bunch of not() clauses to set anchors in
docblocks to blue.
Instead, we should set the default color for <a> to blue (or equivalent in other themes), and override it for places like the sidebar or search results, where we don't want them to be styled as links.
Demo at https://rustdoc.crud.net/jsha/theme-anchor/std/string/struct.String.html. This should result in no visible changes.
r? `@GuillaumeGomez`
Doc Jones mentioned that one of the things making it hard to get started
is that the amount of information is overwhelming, between the
dev-guide, contributing guide, and discussion platforms. This gives
people a single link they can click to ask for help.
