Skip to content

Start using pattern types in libcore #136006

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jan 24, 2025

cc #135996

blocked on rust-analyzer getting support for computing the right layout for pattern types

cc @Veykril no rush here, as long as we can't replace NonNull, there's no point in doing this change just yet

@rustbot

This comment was marked as outdated.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 24, 2025
@oli-obk oli-obk added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 24, 2025
@rust-log-analyzer

This comment has been minimized.

Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well r=me when/if it does get unblocked.

@rust-log-analyzer

This comment has been minimized.

#[repr(transparent)]
$(#[$m])*
#[cfg(not(bootstrap))]
$vis struct $name(pattern_type!($int is $low..=$high));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure: at least for the NonZeroBlahInner ones, it'd be nicer if these could just be type $name = pattern_type!($int is $low..=$high);, without the extra wrapper. Is that feasible, or are the trait implementations too far off?

(Relatedly, I'd love to be able to just derive traits on these again, particularly to not have to manually StructuralPartialEq.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea... I wanna get there, but directly using pattern types is not a great experience at present

@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Jan 27, 2025

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@Veykril
Copy link
Member

Veykril commented Jan 27, 2025

Re rust-analyzer blocker, as it turns out to implement pattern types (to a degree that would unblock this) it comes down to the same architecture changes required as for rust-lang/rust-analyzer#7434 (which I am currently looking into), so that will take a bit.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Jan 27, 2025

Some changes occurred to the CTFE machinery

cc @rust-lang/wg-const-eval

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

@rust-log-analyzer

This comment has been minimized.

@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 11, 2025

Re rust-analyzer blocker, as it turns out to implement pattern types (to a degree that would unblock this) it comes down to the same architecture changes required as for rust-lang/rust-analyzer#7434 (which I am currently looking into), so that will take a bit.

@Veykril I think for the most part you could just treat pattern types opaquely and ignore the pattern's details. Casts to the base type don't require looking at the pattern and instantiating pattern types from literals could just be ignored by r-a and left to rustc. I don't think you actually need the layout of pattern types for anything else

@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk force-pushed the push-tzonluoyuwkq branch from 308a384 to 3e87ee2 Compare March 11, 2025 15:18
@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk force-pushed the push-tzonluoyuwkq branch from 3e87ee2 to f1070f2 Compare March 11, 2025 16:16
@rust-log-analyzer

This comment has been minimized.

@Veykril
Copy link
Member

Veykril commented Mar 12, 2025

Re rust-analyzer blocker, as it turns out to implement pattern types (to a degree that would unblock this) it comes down to the same architecture changes required as for rust-lang/rust-analyzer#7434 (which I am currently looking into), so that will take a bit.

@Veykril I think for the most part you could just treat pattern types opaquely and ignore the pattern's details. Casts to the base type don't require looking at the pattern and instantiating pattern types from literals could just be ignored by r-a and left to rustc. I don't think you actually need the layout of pattern types for anything else

But isn't the point of them that they have niches? If we treat them opaquely we won't see the niches of the type for layout calculation.

Either way I should be unblocked regarding rust-lang/rust-analyzer#7434 so I can start working on that again starting next week. Though if you want to get this merged and r-a is the remaining blocking reason we can work around it by special casing the relevant std/core type(s) if needed I think

@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 12, 2025

But isn't the point of them that they have niches? If we treat them opaquely we won't see the niches of the type for layout calculation.

Ah then the sizes shown by ra would be wrong. Hmm I've never seem the sizes, didn't think about that

@oli-obk oli-obk force-pushed the push-tzonluoyuwkq branch from f1070f2 to bbf47b3 Compare March 12, 2025 09:03
@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk force-pushed the push-tzonluoyuwkq branch from bbf47b3 to c5481a8 Compare March 12, 2025 09:13
@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk force-pushed the push-tzonluoyuwkq branch from c5481a8 to 6f2e921 Compare March 12, 2025 10:17
@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk force-pushed the push-tzonluoyuwkq branch from 6f2e921 to e65f76e Compare March 13, 2025 12:39
@rustbot
Copy link
Collaborator

rustbot commented Mar 13, 2025

The Miri subtree was changed

cc @rust-lang/miri

@bors
Copy link
Collaborator

bors commented Mar 15, 2025

☔ The latest upstream changes (presumably #138464) made this pull request unmergeable. Please resolve the merge conflicts.

@oli-obk oli-obk force-pushed the push-tzonluoyuwkq branch from e65f76e to 7bbf6e9 Compare April 28, 2025 08:01
@Veykril
Copy link
Member

Veykril commented Apr 28, 2025

Btw, the implementation block has been lifted in r-a. (that is the pre-requisite work for rust-lang/rust-analyzer#7434). But since we still use chalk's IR we can't represent pattern types in the type system yet, so that's still kind of blocked there.

@oli-obk oli-obk force-pushed the push-tzonluoyuwkq branch from 7bbf6e9 to 92fedff Compare May 2, 2025 16:37
@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)
info: removing rustup binaries
info: rustup is uninstalled
##[group]Image checksum input
mingw-check-tidy
# We use the ghcr base image because ghcr doesn't have a rate limit
# and the mingw-check-tidy job doesn't cache docker images in CI.
FROM ghcr.io/rust-lang/ubuntu:22.04

ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends \
  g++ \
---

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,cpp
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile --allow-unsafe --generate-hashes reuse-requirements.in
---
#12 3.212 Building wheels for collected packages: reuse
#12 3.213   Building wheel for reuse (pyproject.toml): started
#12 3.454   Building wheel for reuse (pyproject.toml): finished with status 'done'
#12 3.455   Created wheel for reuse: filename=reuse-4.0.3-cp310-cp310-manylinux_2_35_x86_64.whl size=132719 sha256=5bb60f62728aaedff7162745ce743c7f2f55069b3e7f82e6a37d70df455797cc
#12 3.455   Stored in directory: /tmp/pip-ephem-wheel-cache-u6x5v2rb/wheels/3d/8d/0a/e0fc6aba4494b28a967ab5eaf951c121d9c677958714e34532
#12 3.458 Successfully built reuse
#12 3.458 Installing collected packages: boolean-py, binaryornot, tomlkit, reuse, python-debian, markupsafe, license-expression, jinja2, chardet, attrs
#12 3.907 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
#12 3.907 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
#12 4.550 Collecting virtualenv
#12 4.587   Downloading virtualenv-20.30.0-py3-none-any.whl (4.3 MB)
#12 4.659      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.3/4.3 MB 61.8 MB/s eta 0:00:00
#12 4.706 Collecting distlib<1,>=0.3.7
#12 4.711   Downloading distlib-0.3.9-py2.py3-none-any.whl (468 kB)
#12 4.719      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 469.0/469.0 KB 75.6 MB/s eta 0:00:00
#12 4.756 Collecting platformdirs<5,>=3.9.1
#12 4.759   Downloading platformdirs-4.3.7-py3-none-any.whl (18 kB)
#12 4.799 Collecting filelock<4,>=3.12.2
#12 4.806   Downloading filelock-3.18.0-py3-none-any.whl (16 kB)
#12 4.893 Installing collected packages: distlib, platformdirs, filelock, virtualenv
#12 5.092 Successfully installed distlib-0.3.9 filelock-3.18.0 platformdirs-4.3.7 virtualenv-20.30.0
#12 5.092 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
#12 DONE 5.2s

#13 [7/8] COPY host-x86_64/mingw-check/validate-toolstate.sh /scripts/
#13 DONE 0.0s
---
DirectMap4k:      124864 kB
DirectMap2M:     5117952 kB
DirectMap1G:    13631488 kB
##[endgroup]
Executing TIDY_PRINT_DIFF=1 python2.7 ../x.py test            --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
+ TIDY_PRINT_DIFF=1 python2.7 ../x.py test --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
##[group]Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.05s
##[endgroup]
WARN: currently no CI rustc builds have rustc debug assertions enabled. Please either set `rust.debug-assertions` to `false` if you want to use download CI rustc or set `rust.download-rustc` to `false`.
[TIMING] core::build_steps::tool::LibcxxVersionTool { target: x86_64-unknown-linux-gnu } -- 0.260
---
[TIMING] core::build_steps::tool::Tidy { compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu, forced_compiler: false }, target: x86_64-unknown-linux-gnu } -- 0.000
fmt check
fmt: checked 6000 files
tidy check
tidy error: /checkout/compiler/rustc_hir_analysis/messages.ftl: message `hir_analysis_coerce_unsized_may` appears before `hir_analysis_coerce_same_pat_kind`, but is alphabetically later than it
run `./x.py test tidy --bless` to sort the file correctly
tidy: Skipping binary file check, read-only filesystem
removing old virtual environment
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'venv'
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'virtualenv'
Requirement already satisfied: pip in ./build/venv/lib/python3.10/site-packages (25.0.1)
Collecting pip
  Downloading pip-25.1.1-py3-none-any.whl.metadata (3.6 kB)
Downloading pip-25.1.1-py3-none-any.whl (1.8 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 106.3 MB/s eta 0:00:00
Installing collected packages: pip
---
All checks passed!
checking python file formatting
26 files already formatted
checking C++ file formatting
some tidy checks failed
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:01:51
  local time: Fri May  2 16:48:29 UTC 2025
  network time: Fri, 02 May 2025 16:48:29 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-blocked Status: Blocked on something else such as an RFC or other implementation work. 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.

10 participants