Skip to content

Conversation

jieyouxu
Copy link
Member

@jieyouxu jieyouxu commented Feb 3, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

sayantn and others added 18 commits January 6, 2025 11:16
only MUSL needs those objects and trying to compile them to other
targets, e.g. Windows or macOS, will produce C compilation errors

check the target before shelling out to the C compiler and tweak
`make_run` to skip the actual C compilation when the target is not MUSL

fixes rust-lang#135782
- Add wrapper macros for `error!`, `warn!`, `info!`, `debug!` and
  `trace!`, which `cfg(feature = "tracing")`-gates the underlying
  `tracing` macros.
- This is not done for `span!` or `event!` because they can return span
  guards, and you can't really wrap that.
- This is also not possible for `tracing::instrument` attribute
  proc-macro unless you use another attribute proc-macro to wrap that.
… r=camelid

fix(rustdoc): always use a channel when linking to doc.rust-lang.org

Closes rust-lang#131971

I manually checked the resulting links

One issue is that this will create `nightly/...` links in places that formerly linked to stable, is that ok ? (the `slice` and `array` links in the search help notably)
Add `kl` and `widekl` target features, and the feature gate

This is an effort towards rust-lang#134813. This PR adds the target-features and the feature gate to `rustc`

<!--
`@rustbot` label O-x86_64 O-x86_32 A-target-feature
r? compiler
-->
…ly-for-musl, r=onur-ozkan

bootstrap: only build `crt{begin,end}.o` when compiling to MUSL

only MUSL needs those objects and trying to compile them to other targets, e.g. Windows or macOS, will produce C compilation errors

check the target before shelling out to the C compiler and tweak `make_run` to skip the actual C compilation when the target is not MUSL

fixes rust-lang#135782

see the linked issue for additional context
Port ui/simd tests to use the intrinsic macro
Pretty print pattern type values with transmute if they don't satisfy their pattern

Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`.

These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code.

follow-up to rust-lang#136176

cc ```@compiler-errors``` ```@scottmcm```

r? ```@RalfJung``` because of the interpreter changes
set rustc dylib on manually constructed rustc command

Fixes rust-lang#133629
bootstrap: add wrapper macros for `feature = "tracing"`-gated `tracing` macros

Follow-up to rust-lang#136091 (comment).

- Add wrapper macros for `error!`, `warn!`, `info!`, `debug!` and `trace!`, which `cfg(feature = "tracing")`-gates the underlying `tracing` macros. They expand to nothing if `"tracing"` feature is not enabled.
- This is not done for `span!` or `event!` because they can return span guards, and you can't really wrap that.
- This is also not possible for `tracing::instrument` attribute proc-macro unless you use another attribute proc-macro to wrap that.

It's not *great*, because `tracing::instrument` and `tracing::{span,event}` can't be wrapped this way.

Can test locally with:

```bash
$ BOOTSTRAP_TRACING=bootstrap=TRACE ./x check src/bootstrap/
```

r? ```@onur-ozkan``` (or reroll)
mir_build: Simplify `lower_pattern_range_endpoint`

By accumulating ascriptions and inline-consts in separate vectors, we can streamline some previously-tricky code for dealing with range patterns.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler 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 Feb 3, 2025
@jieyouxu
Copy link
Member Author

jieyouxu commented Feb 3, 2025

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Feb 3, 2025

📌 Commit 74901e2 has been approved by jieyouxu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 3, 2025
@bors
Copy link
Collaborator

bors commented Feb 3, 2025

⌛ Testing commit 74901e2 with merge a74589f...

bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 3, 2025
Rollup of 8 pull requests

Successful merges:

 - rust-lang#134807 (fix(rustdoc): always use a channel when linking to doc.rust-lang.org)
 - rust-lang#134814 (Add `kl` and `widekl` target features, and the feature gate)
 - rust-lang#135836 (bootstrap: only build `crt{begin,end}.o` when compiling to MUSL)
 - rust-lang#136022 (Port ui/simd tests to use the intrinsic macro)
 - rust-lang#136235 (Pretty print pattern type values with transmute if they don't satisfy their pattern)
 - rust-lang#136309 (set rustc dylib on manually constructed rustc command)
 - rust-lang#136392 (bootstrap: add wrapper macros for `feature = "tracing"`-gated `tracing` macros)
 - rust-lang#136462 (mir_build: Simplify `lower_pattern_range_endpoint`)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-rust-for-linux failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
   Compiling rustc_const_eval v0.0.0 (/checkout/compiler/rustc_const_eval)
error[E0308]: mismatched types
   --> compiler/rustc_const_eval/src/lib.rs:61:63
    |
61  |         |tcx, scalar, layout| util::validate_scalar_in_layout(tcx, scalar, layout);
    |                               ------------------------------- ^^^ expected `TyCtxtAt<'_>`, found `TyCtxt<'_>`
    |                               arguments to this function are incorrect
    |
note: function defined here
   --> compiler/rustc_const_eval/src/util/check_validity_requirement.rs:172:15

@bors
Copy link
Collaborator

bors commented Feb 3, 2025

💔 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 Feb 3, 2025
@jieyouxu jieyouxu deleted the rollup-ffa9eh8 branch February 3, 2025 20:08
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. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler 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.