Rollup of 9 pull requests #88359
Closed
Rollup of 9 pull requests #88359
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As suggested in rust-lang#86307.
This should cause a compiler error in the future if more variants are added without `Node::ident()` being updated.
Refactors the `type_op_ascribe_user_type` query into a version which accepts a span, and uses it in the nicer NLL HRTB bound region errors.
Some of these tests have reached parity with the migrate-mode output.
This works by doing two things: - Adding links that are specific to the crate. Since not all primitive items are defined in `core` (due to lang_items), these need to use relative links and not intra-doc links. - Duplicating `primitive_docs` in both core and std. This allows not needing CARGO_PKG_NAME to build the standard library. It also adds a tidy check to make sure they stay the same.
- Fix broken handling of primitive associated items - Remove fragment hack Fixes 83083 - more logging - Update CrateNum hacks The CrateNum has no relation to where in the dependency tree the crate is, only when it's loaded. Explicitly special-case core instead of assuming it will be the first DefId. - Update and add tests - Cache calculation of primitive locations This could possibly be avoided by passing a Cache into collect_intra_doc_links; but that's a much larger change, and doesn't seem valuable other than for this.
Most of these are because alloc uses `#[lang_item]` to define methods, but core documents primitives before those methods are available. - Fix run-make-fulldeps test I don't know why it assumed it could build core without cargo ... - Fix rustdoc-js-std test For some reason this change made CStr not show up in the results for `str,u8`. Since it still shows up for str, and since it wasn't a great match for that query anyway, I think this is ok to let slide. - Add test that all primitives can be linked to - Enable `doc(primitive)` in `core` as well
* Highlight the whole pattern if it has no fields * Highlight the whole definition if it has no fields * Only highlight the pattern name if the pattern is multi-line * Determine whether a pattern is multi-line based on distance from name to last field, rather than first field
This reverts commit dbadab5. This is not part of TAITs, so, if tested should probably be done elsewhere.
…omez Fix rustdoc handling of primitive items This is a complicated PR and does a lot of things. I'm willing to split it up a little more if it would help reviewing, but it would be tricky and I'd rather not unless it's necessary. ## What does this do? - Fixes rust-lang#73423. - Fixes rust-lang#79630. I'm not sure how to test this for the standard library explicitly, but you can see from some of the diffs from the `no_std` tests. I also tested it locally and it works correctly:  - Fixes rust-lang#83083. ## Why are these changes interconnected? - Allowing anchors (rust-lang#83083) without fixing the online/offline problem (rust-lang#79630) will actually just silently discard the anchors, that's not a fix. The online/offline problem is directly related to the fragment hack; links need to go through `fn href()` to be fixed. - Technically I could fix the online/offline problem without removing the error on anchors; I am willing to separate that out if it would be helpful for reviewing. However I can't fix the anchor problem without adding docs to core, since rustdoc needs all those primitives to have docs to avoid a fallback, and currently `#![no_std]` crates don't have docs for primitives. I also can't fix the online/offline problem without removing the fragment hack, since otherwise diffs like this will be wrong for some primitives but not others: ```diff `@@` -385,7 +381,7 `@@` fn resolve_primitive_associated_item( ty::AssocKind::Const => "associatedconstant", ty::AssocKind::Type => "associatedtype", }; - let fragment = format!("{}#{}.{}", prim_ty.as_sym(), out, item_name); + let fragment = format!("{}.{}", out, item_name); (Res::Primitive(prim_ty), fragment, Some((kind.as_def_kind(), item.def_id))) }) }) ``` - Adding primitive docs to core without making any other change will cause links to go to `core` instead of `std`, even for crates with `extern crate std`. See "Breaking changes to doc(primitive)" below for why this is the case. That said, I could add some special casing to rustdoc at the same time that would let me separate this change from the others (it would fix rust-lang#73423 but still special-case intra-doc links). I'm willing to separate that out if helpful for reviewing. ### Add primitive documentation to libcore This works by reusing the same `include!("primitive_docs.rs")` file in both core and std, and then special-casing links in core to use relative links instead of intra-doc links. This doesn't use purely intra-doc links because some of the primitive docs links to items only in std; this doesn't use purely relative links because that introduces new broken links when the docs are re-exported (e.g. String's `&str` deref impl, or Vec's slice deref impl). ### Fix inconsistent online/offline primitive docs This does four things: - Records modules with `doc(primitive)` in `cache.external_paths`. This is necessary for `href()` to find them later. - Makes `cache.primitive_locations` available to the intra-doc link pass, by refactoring out a `PrimitiveType::primitive_locations` function that only uses `TyCtxt`. - Special cases modules with `doc(primitive)` to be treated as always public for the purpose of links. - Removes the fragment hack. cc `@notriddle,` I know you added some comments about this in the code (thank you for that!) ### Breaking changes to `doc(primitive)` "Breaking" is a little misleading here - these are changes in behavior, none of them will cause code to fail to compile. Let me preface this by saying I think stabilizing `doc(primitive)` was a uniquely terrible idea. As far as I can tell, it was stabilized by oversight; it's been stable since 1.0. No one should have need to use it except the standard library, and a crater run shows that in fact no one is using it: rust-lang#87050 (comment). I hope to actually make `doc(primitive)` a no-op unless you opt-in with a nightly feature, which will keep crates compiling without forcing rustdoc into trying to keep somewhat arbitrary behavior guarantees; but for now, this just subtly changes some of the behavior if you use `doc(primitive)` in a dependency. That said, here are the changes: - Refactoring out `primitive_locations()` is technically a change in behavior, since it no longer looks for primitives in crates that were passed through `--extern`, but not used by the crate; however, that seems like such an unlikely edge case it's not worth dealing with. - The precedence given to primitive locations is no longer just arbitrary, it can also be inconsistent from run to run. Let me explain that more: previously, primitive locations were sorted by the `CrateNum`; the comment on that sort said "Favor linking to as local extern as possible, so iterate all crates in reverse topological order." Unfortunately, that's not actually what CrateNum tracks: it measures the order crates are loaded, not the number of intermediate crates between that dependency and the root crate. It happened to work as intended before because the compiler injects `extern crate std;` at the top of every crate, which ensured it would have the first CrateNum other than the current, but every other CrateNum was completely arbitrary (for example, `core` often had a later CrateNum than `std`). This now removes the sort on CrateNum completely and special-cases core instead. In particular, if you depend on both `std` and a crate which defines a `doc(primitive)` module, it's arbitrary whether rustdoc will use the docs from std or the ones from the other crate. cc `@alexcrichton,` you wrote this originally. cc `@rust-lang/rustdoc` cc `@rust-lang/libs` for the addition to `core` (the commit you're interested in is rust-lang@36729b0)
…tebank Make spans for tuple patterns in E0023 more precise As suggested in rust-lang#86307. Closes rust-lang#86307. r? ``@estebank``
Don't stabilize creation of TryReserveError instances rust-lang#48043 + rust-lang#87993 (comment)
…sakis Handle type ascription type ops in NLL HRTB diagnostics Currently, there are still a few cases of the "higher-ranked subtype error" of yore, 4 of which are related to type ascription. This PR is a follow-up to rust-lang#86700, adding support for type ascription type ops, and makes 3 of these tests output the same diagnostics in NLL mode as the migrate mode (and 1 is now much closer, especially if you ignore that it already outputs an additional error in NLL mode -- which could be a duplicate caused by a lack of normalization like [these comments point out](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/compiler/rustc_traits/src/type_op.rs#L122-L157), or an imprecision in some parts of normalization as [described here](rust-lang#86700 (comment))). Since we discussed these recently: - [here](rust-lang#86700 (comment)), cc ``@matthewjasper,`` - and [here](rust-lang#57374 (comment)), cc ``@Aaron1011.`` It should only leave [this TAIT test](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.rs) as still emitting [the terse error](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.nll.stderr). r? ``@estebank`` (so that they shake their fist at NLL's general direction less often) or ``@nikomatsakis`` or matthew or aaron, the more the merrier.
…akis type_implements_trait consider obligation failure on overflow Fixes: rust-lang#88103
Add `c_size_t` and `c_ssize_t` to `std::os::raw`. Apparently these aren't guaranteed to be the same, and are merely "always the same in practice" (see https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/.60usize.60.20vs.20.60size_t.60). This is a big footgun, but I suspect it can be alleviated if we expose this and start migrating people to it in advance of any platforms that ever have this as different. I'll file a tracking issue after this gets some traction.
…=jackh726 Revert "Add type of a let tait test impl trait straight in let" This reverts commit dbadab5. This is not part of TAITs, so, if tested should probably be done elsewhere. r? ``@oli-obk`` This is similar to what I was commenting here rust-lang#88332 (comment) These is not part of TAITs so should not live in type-alias-impl-trait test directory. I'm going to avoid adding this kind of tests in `type-alias-impl-trait` test directory and avoid thinking about them in this pass.
…=oli-obk Add field types tait tests r? ``@oli-obk`` Related to rust-lang#86727
…test, r=oli-obk Add const and static TAIT tests r? ``@oli-obk`` Related to rust-lang#86727
|
@bors: r+ p=9 rollup=never |
|
📌 Commit e302595 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit e302595 with merge baf6b2b74763fe77e5ecf71e0bcef3f4a57618ad... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
Problem from #87073 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
c_size_tandc_ssize_ttostd::os::raw. #88340 (Addc_size_tandc_ssize_ttostd::os::raw.)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup