Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 9 pull requests #83422

Closed
wants to merge 32 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

osa1 and others added 30 commits March 12, 2021 10:08
Co-authored-by: the8472 <the8472@users.noreply.github.com>
Its type is called `clean::Span`, and also the name in the rest of
rustdoc and rustc for this kind of field is `span`.
Otherwise you get a lot of instances of `item.span.span()`, which is
just plain confusing. `item.span.inner()` conveys the correct meaning of
"get the type that `clean::Span` wraps".
* It is called `source` in rustc and the rest of rustdoc
* It is not a span, rather it is the source of the import
The rustdoc-json-types renames are breaking changes.
...and add docs to the types instead of the fields that hold the types.
These tests were added to master after I made my changes.
In the analysis use `resolve_vars_if_possible` instead of `fully_resolve`,
because we might not have performed regionck yet.

Fixes: rust-lang#83176
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
…n514

Rename `source` to `span` and `span` to `source`

- Rename `clean::Item.source` to `span`
- Rename `clean::Span::span()` to `clean::Span::inner()`
- Rename `rustdoc_json_types::Item.source` to `span`
- rustdoc-json: Rename `Import.span` to `Import.source`

*See also the [discussion on Zulip][z] (this is a bit more than discussed in
that conversation, but all the changes are related).*

r? ``@jyn514``

[z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/get.20span.20of.20file.20from.20name/near/229603729
Only enable assert_dep_graph when query-dep-graph is enabled.

This is a debugging option. The only effect should be on rustc tests.

r? `@michaelwoerister`
Add internal io::Error::new_const to avoid allocations.

This makes it possible to have a io::Error containing a message with zero allocations, and uses that everywhere to avoid the *three* allocations involved in `io::Error::new(kind, "message")`.

The function signature isn't perfect, because it needs a reference to the `&str`. So for now, this is just a `pub(crate)` function. Later, we'll be able to use `fn new_const<MSG: &'static str>(kind: ErrorKind)` to make that a bit better. (Then we'll also be able to use some ZST trickery if that would result in more efficient code.)

See rust-lang#83352
2229 migration: Don't try resolve regions before writeback

In the analysis use `resolve_vars_if_possible` instead of `fully_resolve`,
because we might not have performed regionck yet.

Fixes: rust-lang#83176

r? `@nikomatsakis`
Change `-W help` to display edition level.

`-W help` was not honoring the `--edition` flag when displaying the default lint level. It was using the edition for sorting, but not for the final display.

This isn't important right now as there aren't any edition-specific lint levels. Also, the `declare_lint` macro is broken and doesn't even allow setting them right now. However, I figure it wouldn't hurt to fix this before I forget about it, in case edition-specific lints are ever used in the future.
…sition, r=Nemo157

Codeblock tooltip position

The codeblocks tooltips were misplaced. Normally, there is no top margin applied to a tooltip unless the codeblock is the first element of the doc block. The CSS rule was too vague though, applying it to all tooltips where the codeblock was the first child of its parent. Which can be easily seen with lists:

Before:

![Screenshot from 2021-03-22 22-05-16](https://user-images.githubusercontent.com/3050060/112059812-a667ba80-8b5c-11eb-88dd-1c598ceb3766.png)

After:

![Screenshot from 2021-03-22 22-06-31](https://user-images.githubusercontent.com/3050060/112059815-a7005100-8b5c-11eb-9e40-8fc57513e498.png)

r? `@Nemo157`
…aumeGomez

Slight visual improvements to warning boxes in the docs

First I noticed that sometimes the thumbs-down emoji in the docs is hard to see and hard to look at because the yellow emoji color and the color of the box below are so bright. Especially if you look at the screen late at night you can notice it. I thought I should change that so I added a black outline around the emoji. It works using the [`text-shadow`](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow) property. It may be a bit hacky but it seems to work well and browser compatibility looks pretty good too: [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow#browser_compatibility).
For consistency the microscope has the black border too.
Alternatively I had `drop-shadow(0px 0px 1px black);` in mind but its [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/drop-shadow()#browser_compatibility) doesn't look as good and the blurry shadow probably doesn't look as good either.

Then, I thought that now that I'm at it I could also try changing the purple color to a color you would rather expect to see for deprecation: red. For the red I've taken the blue and reused it as a foundation and moved it to the red color spectrum.
But then I thought that the purple color could still be reused for something else: for the boxes that tell you about portability (e.g. _only supported on Unix_). These are currently blue.

I think blue doesn't really represent danger like it should. Not being cross-platform represents a danger because if you want to compile for a different platform, your code may not compile anymore. Blue looks too friendly and is in my opinion more suitable for a box containing general information like for instance "This is available since 1.0.0". None of the current three box types (unstable, deprecated and portability) are that.

I think purple is a better fit for it because it's kind of in the middle between "use it" and "don't use it". Deprecated is definitely "don't use it". To illustrate this better, here's a color spectrum:

Blue = friendly,  "use it".
![image](https://user-images.githubusercontent.com/35064754/112139891-9a6b0f80-8bd3-11eb-94e1-dc747a3d4cf9.png)
Red = danger, "don't use it".

And the purple in the middle (the color that the portability box now has) probably represents "use it if you have to", so it's not entirely friendly and not entirely a danger. That is why I think it fits.

However I made one change to that existing purple: I made the outer color a bit brighter because it's outstandingly dark compared to the other outer colors of the other boxes.

This is all subjective but in my opinion it looks nicer. At first you might need to get used to it though. Notice the box colors and the black outlines around the emoji shapes:
![image](https://user-images.githubusercontent.com/35064754/112139327-ebc6cf00-8bd2-11eb-88ac-25219b43a1a0.png)
![image](https://user-images.githubusercontent.com/35064754/112139392-000acc00-8bd3-11eb-90c2-81feec93c521.png)
Update cargo

8 commits in 90691f2bfe9a50291a98983b1ed2feab51d5ca55..58a961314437258065e23cb6316dfc121d96fb71
2021-03-16 21:36:55 +0000 to 2021-03-22 22:59:56 +0000
- Emit note when `--future-incompat-report` had nothing to report (rust-lang/cargo#9263)
- RFC 3052: Stop including authors field in manifests made by cargo new (rust-lang/cargo#9282)
- Refactor feature handling, and improve error messages. (rust-lang/cargo#9290)
- Split out cargo-util package for cargo-test-support. (rust-lang/cargo#9292)
- Fix redundant_semicolons warning in resolver-tests. (rust-lang/cargo#9293)
- Use serde's error message option to avoid implementing `Deserialize`. (rust-lang/cargo#9237)
- Allow `cargo update` to operate with the --offline flag (rust-lang/cargo#9279)
- Fix typo in faq.md (rust-lang/cargo#9285)
@rustbot rustbot added the rollup A PR which is a rollup label Mar 23, 2021
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Mar 23, 2021

📌 Commit 2ee9b37 has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 23, 2021
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
  SCCACHE_BUCKET: rust-lang-ci-sccache2
  TOOLSTATE_REPO: https://github.com/rust-lang-nursery/rust-toolstate
  CACHE_DOMAIN: ci-caches.rust-lang.org
  EXTRA_VARIABLES: {
 "CI_ONLY_WHEN_SUBMODULES_CHANGED": 1
##[endgroup]
adding extra environment variable CI_ONLY_WHEN_SUBMODULES_CHANGED
linux builder detected, using docker to run the build
##[group]Run src/ci/scripts/should-skip-this.sh
---

error[E0432]: unresolved import `cargo::util::ProcessBuilder`
  --> src/tools/rls/rls/src/build/cargo.rs:19:18
   |
19 |     ConfigValue, ProcessBuilder,
   |                  ^^^^^^^^^^^^^^ no `ProcessBuilder` in `util`
error[E0432]: unresolved import `cargo::util::ProcessBuilder`
  --> src/tools/rls/rls/src/build/cargo_plan.rs:25:5
   |
25 | use cargo::util::ProcessBuilder;
25 | use cargo::util::ProcessBuilder;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `ProcessBuilder` in `util`

error[E0432]: unresolved imports `cargo::util::process`, `cargo::util::ProcessBuilder`
  --> src/tools/rls/rls/src/build/external.rs:26:19
   |
26 | use cargo::util::{process, ProcessBuilder};
   |                   ^^^^^^^  ^^^^^^^^^^^^^^ no `ProcessBuilder` in `util`
   |                   |
   |                   no `process` in `util`
   |                   help: a similar name exists in the module: `progress`
error[E0432]: unresolved import `cargo::util::ProcessBuilder`
  --> src/tools/rls/rls/src/build/plan.rs:15:5
   |
15 | use cargo::util::ProcessBuilder;
15 | use cargo::util::ProcessBuilder;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `ProcessBuilder` in `util`

error[E0433]: failed to resolve: could not find `paths` in `util`
    |
    |
269 |     cargo::util::paths::create_dir_all_excluded_from_backups_atomic(
    |                  ^^^^^ could not find `paths` in `util`

error[E0560]: struct `CompileOptions` has no field named `features`
    |
    |
232 |         features: opts.features,
    |         ^^^^^^^^ `CompileOptions` does not have this field
    |
    = note: available fields are: `build_config`, `cli_features`, `spec`, `filter`, `target_rustdoc_args` ... and 4 others
error[E0560]: struct `CompileOptions` has no field named `all_features`
   --> src/tools/rls/rls/src/build/cargo.rs:233:9
    |
233 |         all_features: opts.all_features,
233 |         all_features: opts.all_features,
    |         ^^^^^^^^^^^^ help: a field with a similar name exists: `cli_features`

error[E0560]: struct `CompileOptions` has no field named `no_default_features`
    |
    |
234 |         no_default_features: opts.no_default_features,
    |         ^^^^^^^^^^^^^^^^^^^ `CompileOptions` does not have this field
    |
    = note: available fields are: `build_config`, `cli_features`, `spec`, `filter`, `target_rustdoc_args` ... and 4 others

error[E0271]: type mismatch resolving `<std::collections::btree_map::Iter<'_, std::string::String, std::option::Option<OsString>> as Iterator>::Item == (_, std::option::Option<_>)`
    |
    |
491 |         for (k, v) in &envs {
    |
    |
    = note: expected tuple `(&std::string::String, &std::option::Option<OsString>)`
               found tuple `(_, std::option::Option<_>)`
error[E0283]: type annotations needed
   --> src/tools/rls/rls/src/build/cargo_plan.rs:53:5
    |
44  |   #[derive(Debug, Default)]
44  |   #[derive(Debug, Default)]
    |                   ------- in this macro invocation
...
53  |       pub(crate) compiler_jobs: HashMap<UnitKey, ProcessBuilder>,
    | 
   ::: /checkout/library/core/src/default.rs:167:1
    |
    |
167 | / pub macro Default($item:item) {
169 | | }
    | |_- in this expansion of `#[derive(Default)]`
    |
    |
    = note: cannot satisfy `_: std::default::Default`
    = note: required by `std::default::Default::default`
error[E0061]: this function takes 8 arguments but 7 arguments were supplied
   --> src/tools/rls/rls/src/project_model.rs:220:5
    |
    |
220 |     ops::resolve_with_previous(registry, ws, &ResolveOpts::everything(), prev, None, &[], true)
    |     |
    |     expected 8 arguments
    |
note: function defined here
note: function defined here
   --> /checkout/src/tools/cargo/src/cargo/ops/resolve.rs:206:8
    |
206 | pub fn resolve_with_previous<'cfg>(

error: aborting due to 11 previous errors

Some errors have detailed explanations: E0061, E0271, E0283, E0432, E0433, E0560.
---
Verifying status of rustfmt...
Verifying status of miri...
Verifying status of embedded-book...
Cloning into 'rust-toolstate'...
error: Tool `rls` has regressed from test-pass to build-fail during beta week.
{"book":"test-pass","rustfmt":"test-pass","rustbook":"test-fail","embedded-book":"test-pass","nomicon":"test-pass","edition-guide":"test-pass","miri":"test-pass","rust-by-example":"test-pass","reference":"test-pass","cargo-miri":"test-fail","rls":"build-fail"}failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test --stage 2 check-tools

@bors
Copy link
Contributor

bors commented Mar 23, 2021

⌛ Testing commit 2ee9b37 with merge be43b38ea7222450f6ada825cff05db55a29800d...

@Dylan-DPC-zz
Copy link
Author

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 23, 2021
@Dylan-DPC-zz Dylan-DPC-zz mentioned this pull request Mar 23, 2021
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
    |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
    | 
   ::: /checkout/library/core/src/default.rs:167:1
    |
167 | / pub macro Default($item:item) {
169 | | }
    | |_- in this expansion of `#[derive(Default)]`
    |
    = note: cannot satisfy `_: std::default::Default`
    = note: cannot satisfy `_: std::default::Default`
    = note: required by `std::default::Default::default`

error[E0061]: this function takes 8 arguments but 7 arguments were supplied
   --> src/tools/rls/rls/src/project_model.rs:220:5
    |
220 |     ops::resolve_with_previous(registry, ws, &ResolveOpts::everything(), prev, None, &[], true)
    |     |
    |     expected 8 arguments
    |
note: function defined here
note: function defined here
   --> /checkout/src/tools/cargo/src/cargo/ops/resolve.rs:206:8
    |
206 | pub fn resolve_with_previous<'cfg>(

error: aborting due to 11 previous errors

Some errors have detailed explanations: E0061, E0271, E0283, E0432, E0433, E0560.
---
Verifying status of rustfmt...
Verifying status of miri...
Verifying status of embedded-book...
Cloning into 'rust-toolstate'...
error: Tool `rls` has regressed from test-pass to build-fail during beta week.
{"book":"test-pass","rust-by-example":"test-pass","rls":"build-fail","rustbook":"test-fail","reference":"test-pass","nomicon":"test-pass","embedded-book":"test-pass","cargo-miri":"test-fail","rustfmt":"test-pass","miri":"test-pass","edition-guide":"test-pass"}failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test --stage 2 check-tools

@bors
Copy link
Contributor

bors commented Mar 23, 2021

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 23, 2021
@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-qijew85 branch March 23, 2021 23:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.