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 13 pull requests #129977

Closed
wants to merge 32 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Noratrieb and others added 30 commits July 7, 2024 13:42
Because it's the target libdir.

`--print` uses the same terminology, and it's a simple way to make it
obviously different from `$sysroot/lib`.
Determining this path occasionally fails locally for unknown reasons, resulting
in the build failing with an unhelpful `StripPrefixError(())` panic message.

In order to track down why that's happening, include some relevant information
in the panic message when that failure occurs.
We recently had an issue because some rustlib files were missing (like: "error[E0463]: can't find crate for rustc_ast")
when building tools that rely on rustc. This patch fixes that by copying those files as required.

Signed-off-by: onur-ozkan <work@onurozkan.dev>
... can not be correctly gated using #[cfg] macro
Signed-off-by: onur-ozkan <work@onurozkan.dev>
…-ozkan

Call the target libdir target libdir

Because it's the target libdir.

`--print` uses the same terminology, and it's a simple way to make it obviously different from `$sysroot/lib`.
…llot

Add an internal lint that warns when accessing untracked data

Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions.

I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough.

r? ``@oli-obk``
…d-items, r=t-rustdoc-frontend

[rustdoc] Sort impl associated items by kinds and then by appearance

Following [this zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/.22Freeze.22.20order.20of.20items.20in.20.28trait.29.20impls.3F), I implemented it.

This brings the following change: impl associated items will now be grouped by kind and will now be first sorted by kind and then by the order they are declared in the source code (like currently).

The kinds are sorted in the following order:
1. Constants
2. Types
3. Functions

The reason behind this order is that associated constants can be used in associated types (like length in arrays) and both associated types and associated constants can be used in associated functions. So if an associated item from the same impl is used, its definition will always be above where it's being used.

cc ```@camelid```
r? ```@notriddle```
…tmcm

clarify that addr_of creates read-only pointers

Stacked Borrows does make this UB, but Tree Borrows does not. This is tied up with rust-lang#56604 and other UCG discussions. Also see [this collection of links](Rust-for-Linux/linux#950 (comment)) where rustc treats `addr_of!` as a "non-mutating use".

So, let's better be careful for now.
…arsan68

bootstrap: Try to track down why `initial_libdir` sometimes fails

When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this:

```text
thread 'main' panicked at src/lib.rs:341:14:
called `Result::unwrap()` on an `Err` value: StripPrefixError(())
```

It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs.

Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have.

So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
…rors

explain why Rvalue::Len still exists

I just spent a bit of time trying to remove this until I realized why that's non-trivial. Let's document that for the next person. :)
…RalfJung

s390x: Fix a regression related to backchain feature

In rust-lang#127506, we introduced a new IBM Z-specific target feature, `backchain`.

This particular `target-feature` was available as a function-level attribute in LLVM 17 and below, so some hacks were used to avoid blowing up LLVM when querying the supported LLVM features.

This led to an unfortunate regression where `cfg!(target-feature = "backchain")` will always return true.

This pull request aims to fix this issue, and a test has been introduced to ensure it will never happen again.

Fixes rust-lang#129927.

r? `@RalfJung`
…=Kobzol

copy rustc rustlib artifacts from ci-rustc

We recently (since rust-lang#129311) had an issue because some rustlib files were missing (like: "error[E0463]: can't find crate for rustc_ast") when building tools that rely on rustc. This patch fixes that by copying those files as required.

r? Kobzol

Blocker for rust-lang#122709
…er, r=Kobzol

use the bootstrapped compiler for `test-float-parse` test

Fixes rust-lang#122709 (comment).

Blocker for rust-lang#122709
…pietroalbini

Add compat note for trait solver change

r? `@pietroalbini` `@BoxyUwU`

cc `@lcnr`
…separators, r=tgross35

Add digit separators in `Duration` examples

`@rustbot` label A-docs
Temporarily remove fmease from the review rotation

Namely for like a week. I seriously need to work off my review backlog!

r? fmease
…bertlarsan68

forward linker option to lint-docs

This fixes an error found when building the doc for a cross-built toolchain.

```
warning: the code example in lint `unstable_syntax_pre_expansion` in /buildroots/chenx97/rustc-1.80.1-src/compiler/rustc_lint_defs/src/builtin.rs failed to generate the expected output: did not find lint `unstable_syntax_p
re_expansion` in output of example, got:

error: linking with `cc` failed: exit status: 1
...
```
Closes: rust-lang#129956
@rustbot rustbot added A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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-libs Relevant to the library team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, 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 Sep 5, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=13

@bors
Copy link
Contributor

bors commented Sep 5, 2024

📌 Commit 4ce79bc has been approved by matthiaskrgr

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 Sep 5, 2024
@rust-log-analyzer
Copy link
Collaborator

The job mingw-check-tidy failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

COPY host-x86_64/mingw-check/validate-toolstate.sh /scripts/
COPY host-x86_64/mingw-check/validate-error-codes.sh /scripts/

# NOTE: intentionally uses python2 for x.py so we can test it still works.
# validate-toolstate only runs in our CI, so it's ok for it to only support python3.
ENV SCRIPT TIDY_PRINT_DIFF=1 python2.7 ../x.py test \
           --stage 0 src/tools/tidy tidyselftest --extra-checks=py:lint,cpp:fmt
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile --allow-unsafe --generate-hashes reuse-requirements.in
---
#13 2.863 Building wheels for collected packages: reuse
#13 2.865   Building wheel for reuse (pyproject.toml): started
#13 3.116   Building wheel for reuse (pyproject.toml): finished with status 'done'
#13 3.117   Created wheel for reuse: filename=reuse-4.0.3-cp310-cp310-manylinux_2_35_x86_64.whl size=132715 sha256=dfa09868353292d98f811d3efdb0d54d07389e808efc71d68e3b93c514bf8bec
#13 3.117   Stored in directory: /tmp/pip-ephem-wheel-cache-h0nt3evc/wheels/3d/8d/0a/e0fc6aba4494b28a967ab5eaf951c121d9c677958714e34532
#13 3.120 Installing collected packages: boolean-py, binaryornot, tomlkit, reuse, python-debian, markupsafe, license-expression, jinja2, chardet, attrs
#13 3.533 Successfully installed attrs-23.2.0 binaryornot-0.4.4 boolean-py-4.0 chardet-5.2.0 jinja2-3.1.4 license-expression-30.3.0 markupsafe-2.1.5 python-debian-0.1.49 reuse-4.0.3 tomlkit-0.13.0
#13 3.533 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
#13 4.067 Collecting virtualenv
#13 4.067 Collecting virtualenv
#13 4.103   Downloading virtualenv-20.26.3-py3-none-any.whl (5.7 MB)
#13 4.184      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.7/5.7 MB 72.6 MB/s eta 0:00:00
#13 4.229 Collecting distlib<1,>=0.3.7
#13 4.232   Downloading distlib-0.3.8-py2.py3-none-any.whl (468 kB)
#13 4.240      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 468.9/468.9 KB 81.2 MB/s eta 0:00:00
#13 4.275 Collecting platformdirs<5,>=3.9.1
#13 4.279   Downloading platformdirs-4.2.2-py3-none-any.whl (18 kB)
#13 4.321 Collecting filelock<4,>=3.12.2
#13 4.325   Downloading filelock-3.15.4-py3-none-any.whl (16 kB)
#13 4.405 Installing collected packages: distlib, platformdirs, filelock, virtualenv
#13 4.596 Successfully installed distlib-0.3.8 filelock-3.15.4 platformdirs-4.2.2 virtualenv-20.26.3
#13 DONE 4.7s

#14 [7/8] COPY host-x86_64/mingw-check/validate-toolstate.sh /scripts/
#14 DONE 0.0s
---
   Compiling build_helper v0.1.0 (/checkout/src/tools/build_helper)
error[E0599]: no method named `sysroot_libdir` found for reference `&core::builder::Builder<'_>` in the current scope
##[error]    --> src/core/build_steps/dist.rs:478:39
     |
478  |                 let src_dir = builder.sysroot_libdir(compiler, host).parent().unwrap().join("bin");
     |
help: there is a method `sysroot` with a similar name, but with different arguments
    --> src/core/builder.rs:1149:5
     |
---
   Compiling bootstrap v0.0.0 (/checkout/src/bootstrap)
error[E0599]: no method named `sysroot_libdir` found for reference `&core::builder::Builder<'_>` in the current scope
##[error]    --> src/core/build_steps/dist.rs:478:39
     |
478  |                 let src_dir = builder.sysroot_libdir(compiler, host).parent().unwrap().join("bin");
     |
help: there is a method `sysroot` with a similar name, but with different arguments
    --> src/core/builder.rs:1149:5
     |
---
   Compiling bootstrap v0.0.0 (/checkout/src/bootstrap)
error[E0599]: no method named `sysroot_libdir` found for reference `&core::builder::Builder<'_>` in the current scope
##[error]    --> src/core/build_steps/dist.rs:478:39
     |
478  |                 let src_dir = builder.sysroot_libdir(compiler, host).parent().unwrap().join("bin");
     |
help: there is a method `sysroot` with a similar name, but with different arguments
    --> src/core/builder.rs:1149:5
     |
---
   Compiling bootstrap v0.0.0 (/checkout/src/bootstrap)
error[E0599]: no method named `sysroot_libdir` found for reference `&core::builder::Builder<'_>` in the current scope
##[error]    --> src/core/build_steps/dist.rs:478:39
     |
478  |                 let src_dir = builder.sysroot_libdir(compiler, host).parent().unwrap().join("bin");
     |
help: there is a method `sysroot` with a similar name, but with different arguments
    --> src/core/builder.rs:1149:5
     |
---
   Compiling bootstrap v0.0.0 (/checkout/src/bootstrap)
error[E0599]: no method named `sysroot_libdir` found for reference `&core::builder::Builder<'_>` in the current scope
##[error]    --> src/core/build_steps/dist.rs:478:39
     |
478  |                 let src_dir = builder.sysroot_libdir(compiler, host).parent().unwrap().join("bin");
     |
help: there is a method `sysroot` with a similar name, but with different arguments
    --> src/core/builder.rs:1149:5
     |

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Area: Issues & PRs about the rust-lang/rust repository itself rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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-libs Relevant to the library team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, 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.