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 5 pull requests #102908

Closed
wants to merge 32 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

joboet and others added 30 commits October 6, 2022 22:46
ADD - migrate MissingNativeStaticLibrary fatal error
This diagnostic has no UI test 🤔 Should we add some? If so, how?
- UPDATE - revert migration of logs

- UPDATE - use derive on LinkRlibError enum

- [Gardening] UPDATE - alphabetically sort fluent_messages

- UPDATE - use PathBuf and unify both AddNativeLibrary to use Display (which is what PathBuf uses when conforming to IntoDiagnosticArg)

- UPDATE - fluent messages sort after rebase
Small tweaks to changes made in a previous PR, unrelated to eager
translation.

Signed-off-by: David Wood <[email protected]>
Eager translation will enable subdiagnostics to be translated multiple
times with different arguments - this requires the ability to replace
the value of one argument with a new value, which is better suited to a
`HashMap` than the previous storage, a `Vec`.

Signed-off-by: David Wood <[email protected]>
`AddToDiagnostic::add_to_diagnostic_with` is similar to the previous
`AddToDiagnostic::add_to_diagnostic` but takes a function that can be
used by the caller to modify diagnostic messages originating from the
subdiagnostic (such as performing translation eagerly).

`add_to_diagnostic` now just calls `add_to_diagnostic_with` with an
empty closure.

Signed-off-by: David Wood <[email protected]>
Add variant of `DiagnosticMessage` for eagerly translated messages
(messages in the target language which don't need translated by the
emitter during emission). Also adds `eager_subdiagnostic` function which
is intended to be invoked by the diagnostic derive for subdiagnostic
fields which are marked as needing eager translation.

Signed-off-by: David Wood <[email protected]>
Add support for `eager` argument to the `subdiagnostic` attribute which
generates a call to `eager_subdiagnostic`.

Signed-off-by: David Wood <[email protected]>
Using eager translation, migrate the remaining repeated cycle stack
diagnostic.

Signed-off-by: David Wood <[email protected]>
Diagnostic derives have previously had to take special care when
ordering the generated code so that fields were not used after a move.

This is unlikely for most fields because a field is either annotated
with a subdiagnostic attribute and is thus likely a `Span` and copiable,
or is a argument, in which case it is only used once by `set_arg`
anyway.

However, format strings for code in suggestions can result in fields
being used after being moved if not ordered carefully. As a result, the
derive currently puts `set_arg` calls last (just before emission), such
as:

```rust
let diag = { /* create diagnostic */ };

diag.span_suggestion_with_style(
    span,
    fluent::crate::slug,
    format!("{}", __binding_0),
    Applicability::Unknown,
    SuggestionStyle::ShowAlways
);
/* + other subdiagnostic additions */

diag.set_arg("foo", __binding_0);
/* + other `set_arg` calls */

diag.emit();
```

For eager translation, this doesn't work, as the message being
translated eagerly can assume that all arguments are available - so
arguments _must_ be set first.

Format strings for suggestion code are now separated into two parts - an
initialization line that performs the formatting into a variable, and a
usage in the subdiagnostic addition.

By separating these parts, the initialization can happen before
arguments are set, preserving the desired order so that code compiles,
while still enabling arguments to be set before subdiagnostics are
added.

```rust
let diag = { /* create diagnostic */ };

let __code_0 = format!("{}", __binding_0);
/* + other formatting */

diag.set_arg("foo", __binding_0);
/* + other `set_arg` calls */

diag.span_suggestion_with_style(
    span,
    fluent::crate::slug,
    __code_0,
    Applicability::Unknown,
    SuggestionStyle::ShowAlways
);
/* + other subdiagnostic additions */

diag.emit();
```

Signed-off-by: David Wood <[email protected]>
Following the approach taken in earlier commits to separate formatting
initialization from use in the subdiagnostic derive, simplify the
diagnostic derive by removing the field-ordering logic that previously
solved this problem.

Signed-off-by: David Wood <[email protected]>
The issue rust-lang#102157 demonstrates how currently the `-Z build-std` option
will fail when re-compiling the standard library with `RUSTFLAGS` like
`RUSTFLAGS="-C target-feature=+atomics,+bulk-memory -C
link-args=--shared-memory"`. This change attempts to resolve those build
issues by depending on the the WebAssembly `futex` module and providing
an implementation for `env_lock`. Fixes rust-lang#102157.
Copying the approach of the Unix target, this change uses the standard
`RwLock` to protect against concurrent access of libc's environment.
This locking is only enabled when WebAssembly's `atomics` feature is
also enabled.
When this was added, the sidebar had a bit more complex style. It can be
removed, now.
Allow compiling the `wasm32-wasi` std library with atomics

The issue rust-lang#102157 demonstrates how currently the `-Z build-std` option will fail when re-compiling the standard library with `RUSTFLAGS` like `RUSTFLAGS="-C target-feature=+atomics,+bulk-memory -C link-args=--shared-memory"`. This change attempts to resolve those build issues by depending on the the WebAssembly `futex` module and providing an implementation for `env_lock`. Fixes rust-lang#102157.
…-diagnostics-structs, r=davidtwco

Migrate `codegen_ssa` to diagnostics structs - [Part 1]

Initial migration of `codegen_ssa`. Going to split this crate migration in at least two PRs in order to avoid a huge PR and to quick off some questions around:

1. Translating messages from "external" crates.
2. Interfacing with OS messages.
3. Adding UI tests while migrating diagnostics.

_See comments below._
…piler-errors

translation: eager translation

Part of rust-lang#100717. See [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20lists!/near/295010720) for additional context.

- **Store diagnostic arguments in a `HashMap`**: Eager translation will enable subdiagnostics to be translated multiple times with different arguments - this requires the ability to replace the value of one argument with a new value, which is better suited to a `HashMap` than the previous storage, a `Vec`.
- **Add `AddToDiagnostic::add_to_diagnostic_with`**: `AddToDiagnostic::add_to_diagnostic_with` is similar to the previous `AddToDiagnostic::add_to_diagnostic` but takes a function that can be used by the caller to modify diagnostic messages originating from the subdiagnostic (such as performing translation eagerly). `add_to_diagnostic` now just calls `add_to_diagnostic_with` with an empty closure.
- **Add `DiagnosticMessage::Eager`**: Add variant of `DiagnosticMessage` for eagerly translated messages
(messages in the target language which don't need translated by the emitter during emission). Also adds `eager_subdiagnostic` function which is intended to be invoked by the diagnostic derive for subdiagnostic fields which are marked as needing eager translation.
- **Support `#[subdiagnostic(eager)]`**: Add support for `eager` argument to the `subdiagnostic` attribute which generates a call to `eager_subdiagnostic`.
- **Finish migrating `rustc_query_system`**: Using eager translation, migrate the remaining repeated cycle stack diagnostic.
- **Split formatting initialization and use in diagnostic derives**: Diagnostic derives have previously had to take special care when ordering the generated code so that fields were not used after a move.

  This is unlikely for most fields because a field is either annotated with a subdiagnostic attribute and is thus likely a `Span` and copiable, or is a argument, in which case it is only used once by `set_arg`
anyway.

  However, format strings for code in suggestions can result in fields being used after being moved if not ordered carefully. As a result, the derive currently puts `set_arg` calls last (just before emission), such as:

      let diag = { /* create diagnostic */ };

      diag.span_suggestion_with_style(
          span,
          fluent::crate::slug,
          format!("{}", __binding_0),
          Applicability::Unknown,
          SuggestionStyle::ShowAlways
      );
      /* + other subdiagnostic additions */

      diag.set_arg("foo", __binding_0);
      /* + other `set_arg` calls */

      diag.emit();

  For eager translation, this doesn't work, as the message being translated eagerly can assume that all arguments are available - so arguments _must_ be set first.

  Format strings for suggestion code are now separated into two parts - an initialization line that performs the formatting into a variable, and a usage in the subdiagnostic addition.

  By separating these parts, the initialization can happen before arguments are set, preserving the desired order so that code compiles, while still enabling arguments to be set before subdiagnostics are added.

      let diag = { /* create diagnostic */ };

      let __code_0 = format!("{}", __binding_0);
      /* + other formatting */

      diag.set_arg("foo", __binding_0);
      /* + other `set_arg` calls */

      diag.span_suggestion_with_style(
          span,
          fluent::crate::slug,
          __code_0,
          Applicability::Unknown,
          SuggestionStyle::ShowAlways
      );
      /* + other subdiagnostic additions */

      diag.emit();

- **Remove field ordering logic in diagnostic derive:** Following the approach taken in earlier commits to separate formatting initialization from use in the subdiagnostic derive, simplify the diagnostic derive by removing the field-ordering logic that previously solved this problem.

r? `@compiler-errors`
Use semaphores for thread parking on Apple platforms

Currently we use a mutex-condvar pair for thread parking on Apple systems. Unfortunately, `pthread_cond_timedwait` uses the real-time clock for measuring time, which causes problems when the system time changes. The parking implementation in this PR uses a semaphore instead, which measures monotonic time by default, avoiding these issues. As a further benefit, this has the potential to improve performance a bit, since `unpark` does not need to wait for a lock to be released.

Since the Mach semaphores are poorly documented (I could not find availability or stability guarantees for instance), this uses a [dispatch semaphore](https://developer.apple.com/documentation/dispatch/dispatch_semaphore?language=objc) instead. While it adds a layer of indirection (it uses Mach semaphores internally), the overhead is probably negligible.

Tested on macOS 12.5.

r? `@thomcc`
… r=GuillaumeGomez

rustdoc: remove unneeded `<div>` wrapper from sidebar DOM

When this was added, the sidebar had a bit more complex style. It can be removed, now.

Preview: https://notriddle.com/notriddle-rustdoc-demos/sidebar-block/std/index.html
@rustbot rustbot added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Oct 11, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Oct 11, 2022

📌 Commit 0f7b622 has been approved by matthiaskrgr

It is now in the queue for this repository.

@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 Oct 11, 2022
@bors
Copy link
Contributor

bors commented Oct 11, 2022

⌛ Testing commit 0f7b622 with merge 33ef5c43973405915feb618101dee183d14e517e...

@rust-log-analyzer
Copy link
Collaborator

The job dist-various-2 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] gimli test:false 4.486
[RUSTC-TIMING] object test:false 5.230
warning: dropping unsupported crate type `dylib` for target `wasm32-wasi`

error[E0277]: the trait bound `(): Drop` is not satisfied
  --> library/std/src/sys/wasi/os.rs:40:35
   |
40 |         pub fn env_read_lock() -> impl Drop {
   |                                   ^^^^^^^^^ the trait `Drop` is not implemented for `()`
41 |             ()
   |             -- return type was inferred to be `()` here

error[E0277]: the trait bound `(): Drop` is not satisfied
  --> library/std/src/sys/wasi/os.rs:43:36
   |
43 |         pub fn env_write_lock() -> impl Drop {
   |                                    ^^^^^^^^^ the trait `Drop` is not implemented for `()`
44 |             ()
   |             -- return type was inferred to be `()` here
For more information about this error, try `rustc --explain E0277`.
[RUSTC-TIMING] std test:false 2.310
warning: `std` (lib) generated 1 warning
error: could not compile `std` due to 2 previous errors; 1 warning emitted

@bors
Copy link
Contributor

bors commented Oct 11, 2022

💔 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 11, 2022
@matthiaskrgr matthiaskrgr deleted the rollup-yuvo6aq branch December 22, 2022 10:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants