As per the discussion in PR #74147, the 4 individual tests are replaced by a
single one.
The test is expanded to cover all 4 public/private cases, each with and without
--document-private-items.
Fixes#74134
After PR #72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.
Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
Rollup of 14 pull requests
Successful merges:
- #70563 ([rustdoc] Page hash handling)
- #73856 (Edit librustc_lexer top-level docs)
- #73870 (typeck: adding type information to projection)
- #73953 (Audit hidden/short code suggestions)
- #73962 (libstd/net/tcp.rs: #![deny(unsafe_op_in_unsafe_fn)])
- #73969 (mir: mark mir construction temporaries as internal)
- #73974 (Move A|Rc::as_ptr from feature(weak_into_raw) to feature(rc_as_ptr))
- #74067 (rustdoc: Restore underline text decoration on hover for FQN in header)
- #74074 (Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`.)
- #74078 (Always resolve type@primitive as a primitive, not a module)
- #74089 (Add rust-analyzer to the build manifest)
- #74090 (Remove unused RUSTC_DEBUG_ASSERTIONS)
- #74102 (Fix const prop ICE)
- #74112 (Expand abbreviation in core::ffi description)
Failed merges:
r? @ghost
Remove unused RUSTC_DEBUG_ASSERTIONS
Since #73374 the rustc wrapper no longer configures debug assertions
based on RUSTC_DEBUG_ASSERTIONS environment variable.
r? @RalfJung
Add rust-analyzer to the build manifest
Does not die locally, produces `rust-analyzer-0.1.0-dev-x86_64-unknown-linux-gnu.tar.gz.sha256` and add something about rust-analyzer to some `.toml` file. Seems like a success?
Always resolve type@primitive as a primitive, not a module
Previously, if there were a module in scope with the same name as the
primitive, that would take precedence. Coupled with
https://github.com/rust-lang/rust/issues/58699, this made it impossible
to link to the primitive when that module was in scope.
This approach could be extended so that `struct@foo` would no longer resolve
to any type, etc. However, it could not be used for glob imports:
```rust
pub mod foo {
pub struct Bar;
}
pub enum Bar {}
use foo::*;
// This is expected to link to `inner::Bar`, but instead it will link to the enum.
/// Link to [struct@Bar]
pub struct MyDocs;
```
The reason for this is that this change does not affect the resolution
algorithm of rustc_resolve at all. The only reason we could special-case
primitives is because we have a list of all possible primitives ahead of time.
Closes https://github.com/rust-lang/rust/issues/74063
r? @Manishearth
Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`.
This adjusts the return type of Windows' `OpenOptionsExt::security_qos_flags`
to be consistent with the other functions in the trait.
rustdoc: Restore underline text decoration on hover for FQN in header
This causes the components of FQN's (e.g. `std`, `net`, and `Ipv4Addr` of the FQN `std::net::Ipv4Addr`) to behave similarly to other links in the contents of rustdoc-styled pages. When the user hovers over them, more clearly indicating that they can be used for navigation.
I (and I hope others at least in part) have found the prior design to be somewhat confusing, as it is not clear (upon hovering) that the various parts of the FQN are actually links that the user can navigate to.
<details><summary>📸 Before, mouse hovered over "net" in the FQN</summary>
<img alt="A rustdoc page with the mouse hovered over the fully-qualified name in the page header, producing no visual change" src="https://user-images.githubusercontent.com/1566689/86538363-4c827000-bebb-11ea-8291-5ea6b85d7e19.png" />
</details>
<details><summary>📸 After, mouse hovered over "net" in the FQN</summary>
<img alt="A rustdoc page with the mouse hovered over the fully-qualified name in the page header, now with an underline showing up under the word hovered over by the mouse" src="https://user-images.githubusercontent.com/1566689/86538471-d3374d00-bebb-11ea-9bb3-7aa2d7a4800b.png" />
</details>
Move A|Rc::as_ptr from feature(weak_into_raw) to feature(rc_as_ptr)
These were stabilized alongside the Weak versions, but having `feature = "weak_.."` on a fn definition for the non-weak pointers is potentially very misleading, especially in a review context where the impl header may not be immediately visible.
r? @RalfJung
@bors rollup=always
mir: mark mir construction temporaries as internal
Fixes#73914.
This PR marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior.
r? @matthewjasper
Audit hidden/short code suggestions
Should fix#73641.
Audit uses of `span_suggestion_short` and `tool_only_span_suggestion` (`span_suggestion_hidden` is already tested with `run-rustfix`). Leave some FIXMEs for futher improvements/fixes.
r? @estebank
typeck: adding type information to projection
This commit modifies the Place as follow:
* remove 'ty' from ProjectionKind
* add type information into to Projection
* replace 'ty' in Place with 'base_ty'
* introduce 'ty()' in `Place` to return the final type of the `Place`
* introduce `ty_before_projection()` in `Place` to return the type of
a `Place` before i'th projection is applied
Closes https://github.com/rust-lang/project-rfc-2229/issues/5
Previously, if there were a module in scope with the same name as the
primitive, that would take precedence. Coupled with
https://github.com/rust-lang/rust/issues/58699, this made it impossible
to link to the primitive when that module was in scope.
This approach could be extended so that `struct@foo` would no longer resolve
to any type, etc. However, it could not be used for glob imports:
```rust
pub mod foo {
pub struct Bar;
}
pub enum Bar {}
use foo::*;
// This is expected to link to `inner::Bar`, but instead it will link to the enum.
/// Link to [struct@Bar]
pub struct MyDocs;
```
The reason for this is that this change does not affect the resolution
algorithm of rustc_resolve at all. The only reason we could special-case
primitives is because we have a list of all possible primitives ahead of time.
Remove unnecessary release from Arc::try_unwrap
The thread that recovers the unique access to Arc inner value (e.g., drop
when ref-count strong reaches zero, successful try_unwrap), ensures that
other operations on Arc inner value happened before by synchronizing
with release operations performed when decrementing the reference counter.
When try_unwrap succeeds, the current thread recovers the unique access
to Arc inner value, so release is unnecessary.
r? @Amanieu
add `lazy_normalization_consts` feature gate
In #71973 I underestimated the amount of code which is influenced by lazy normalization of consts
and decided against having a separate feature flag for this.
Looking a bit more into this, the following issues are already working with lazy norm in its current state #47814#57739#73980
I therefore think it is worth it to enable lazy norm separately. Note that `#![feature(const_generics)]` still automatically activates
this feature, so using `#![feature(const_generics, lazy_normalization_consts)]` is redundant.
r? @varkor @nikomatsakis
Fix try_print_visible_def_path for Rust 2018
The recursive check of `try_print_visible_def_path` did not properly handle the Rust 2018 case of crate-paths without 'extern crate'. Instead, it returned a "not found" via (false, self).
This fixes#56175.
Some refactoring around intrinsic type checking
So... This PR went a bit overboard. I wanted to make the `rustc_peek` intrinsic safe (cc @ecstatic-morse ), and remembered a long-standing itch of mine. So I made that huge `&str` match for the intrinsic name a match on `Symbol`s (so basically `u32`s). This is unlikely to have a positive perf effect, even if it likely has better codegen (intrinsics are used rarely, mostly once in their wrapper), so it's mostly a consistency thing since other places actually match on the symbol name of the intrinsics.
added .collect() into String from Box<str>
I have not created an rfc, because i felt like this is a very minor change.
i have just set a random feature name and rust version as stability attribute, i expect to have to change that, i just don't know what the policy on that is. all guides i could find focused on contributing to the compiler, not contributing to the standard library.
drawbacks: more code in the standard library, could be replaced with specialization: base-implementation for AsRef\<str> and specialization for String and Cow. i can write that code if ppl want it.
advantages: using "real strings" i.e. Box\<str> is as ergonomic as string slices (&str) and string buffers (String) with iterators.
Handle inactive enum variants in `MaybeUninitializedPlaces`
Resolves the first part of #69715.
This is the equivalent of #68528 but for `MaybeUninitializedPlaces`. Because we now notify drop elaboration that inactive enum variants might be uninitialized, some drops get marked as ["open" that were previously "static"](e0e5d82e16/src/librustc_mir/transform/elaborate_drops.rs (L191)). Unlike in #69715, this isn't strictly better: An "open" drop expands to more MIR than a simple call to the drop shim. However, because drop elaboration considers each field of an "open" drop separately, it can sometimes eliminate unnecessary drops of moved-from or unit-like enum variants. This is the case for `Option::unwrap`, which is reflected in the `mir-opt` test.
cc @eddyb
r? @oli-obk
This causes the components of FQN's to behave similarly to other links
in the contents of rustdoc-styled pages.
I (and I hope others at least in part) have found the prior design to be
somewhat confusing, as it is not clear (upon hovering) that the various
parts of the FQN are actually links that the user can navigate to.
In short, this patch makes links in the FQN have an underline when the
user hovers over them, more clearly indicating that they can be used for
navigation.
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
