Skip to content

Rollup of 8 pull requests #133296

New issue

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

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

Already on GitHub? # to your account

Closed
wants to merge 19 commits into from

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

compiler-errors and others added 19 commits November 2, 2024 03:42
The deployment target environment variable is OS-specific, and if you're
in a place where you're asking `rustc` for the deployment target, you're
likely to also wanna know the environment variable.
Stop being so bail-y in candidate assembly

A conceptual follow-up to rust-lang#132084. We gotta stop bailing so much when there are errors; it's both unnecessary, leads to weird knock-on errors, and it's messing up the vibes lol
…BoxyUwU

Fix closure arg extraction in `extract_callable_info`, generalize it to async closures

* Fix argument extraction in `extract_callable_info`
* FIx `extract_callable_info` to work for async closures
* Remove redundant `is_fn_ty` which is just a less general `extract_callable_info`
* More precisely name what is being called (i.e. call it a "closure" not a "function")

Review this without whitespace -- I ended up reformatting `extract_callable_info` because some pesky `//` comments were keeping the let-chains from being formatted.
…v-var, r=davidtwco

Print name of env var in `--print=deployment-target`

The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example.

Behaviour before this PR:
```console
$ rustc --print=deployment-target --target=aarch64-apple-darwin
deployment_target=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
deployment_target=1.0
```

Behaviour after this PR:
```console
$ rustc --print=deployment-target --target=aarch64-apple-darwin
MACOSX_DEPLOYMENT_TARGET=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
XROS_DEPLOYMENT_TARGET=1.0
```

My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this:
- https://github.com/PyO3/maturin/blob/b292ef69349f2a56cb8ab1b59fda0be3d3b9f138/src/build_context.rs#L1199-L1220
- https://github.com/rust-lang/cc-rs/blob/daab9244b03e244c4f2511944870d719c443f61f/src/lib.rs#L3422-L3426

`maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](rust-lang/cc-rs#848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](rust-lang/cc-rs#901) [reverted](rust-lang/cc-rs#943) in `v1.0.85`.

So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine.

`@BlackHoleFox` wdyt?

`@rustbot` label O-apple
r? compiler
tests: ui/inline-consts: add issue number to a test, rename other tests

rename other tests from a_b_c to a-b-c
…iler-errors

Minimally constify `Add`

* This PR removes the requirement for `impl const` to have a const stability attribute. cc `@RalfJung` I believe you mentioned that it would make much more sense to require `const_trait`s to have const stability instead. I agree with that sentiment but I don't think that is _required_ for a small scale experimentation like this PR. rust-lang/project-const-traits#16 should definitely be prioritized in the future, but removing the impl check should be good for now as all callers need `const_trait_impl` enabled for any const impl to work.
* This PR is intentionally minimal as constifying other traits can become more complicated (`PartialEq`, for example, would run into requiring implementing it for `str` as that is used in matches, which runs into the implementation for slice equality which uses specialization)

Per the reasons above, anyone who is interested in making traits `const` in the standard library are **strongly encouraged** to reach out to us on the [Zulip channel](https://rust-lang.zulipchat.com/#narrow/channel/419616-t-compiler.2Fproject-const-traits) before proceeding with the work.

cc `@rust-lang/project-const-traits`

I believe there is prior approval from libs that we can experiment, so

r? project-const-traits
…able, r=Kobzol

ci: Disable full `debuginfo-level=2` in windows alt job

try-job: dist-x86_64-msvc-alt
…lay-impl, r=workingjubilee

Reduce integer `Display` implementation size

I was thinking about rust-lang#128204 and how we could reduce the size of the code and just realized that we didn't need the `_fmt` method to be implemented on signed integers, which in turns allow to simplify greatly the macro call.

r? `@workingjubilee`
Don't exclude relnotes from `needs-triage` label

So initially we *didn't* exclude `needs-triage` label, then we did exclude them in rust-lang#132825 as sometimes the `needs-triage` is redundant. However, I think they are probably worth double-checking because often some of the labels are only accurate/relevant for the *implementation* PR, but not for the purposes of the relnotes tracking issue. Furthermore, sometimes relevant team labels can be removed. So to make it less likely for relnotes to slip through, I think we should still label relnotes-tracking-issues with `needs-triage`.

cc https://rust-lang.zulipchat.com/#narrow/channel/241545-t-release/topic/Please.20CC.20lang

r? release
@rustbot rustbot added A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc 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-infra Relevant to the infrastructure 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. rollup A PR which is a rollup labels Nov 21, 2024
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=8 rollup=never

@bors
Copy link
Collaborator

bors commented Nov 21, 2024

📌 Commit aeb9f6d has been approved by GuillaumeGomez

It is now in the queue for this repository.

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 21, 2024
@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 Nov 21, 2024
@matthiaskrgr
Copy link
Member

@bors r-
overlaps with #133287
also I'm not sure with we should roll up #133246 in case we need to bisect this at some later point

@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 Nov 21, 2024
@GuillaumeGomez
Copy link
Member Author

Fair enough. Maybe we should also add rollup=never on #133246?

@GuillaumeGomez GuillaumeGomez deleted the rollup-9bi7vhr branch November 21, 2024 13:45
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants