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

Hierarchy of Sized traits #3729

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

Conversation

davidtwco
Copy link
Member

@davidtwco davidtwco commented Nov 15, 2024

All of Rust's types are either sized, which implement the Sized trait and have a statically known size during compilation, or unsized, which do not implement the Sized trait and are assumed to have a size which can be computed at runtime. However, this dichotomy misses two categories of type - types whose size is unknown during compilation but is a runtime constant, and types whose size can never be known. Supporting the former is a prerequisite to stable scalable vector types and supporting the latter is a prerequisite to unblocking extern types. This RFC proposes a hierarchy of Sized traits in order to be able to support these use cases.

This RFC relies on experimental, yet-to-be-RFC'd const traits, so this is blocked on that. I haven't squashed any of the previous revisions but can do so if/when this is approved. Already discussed in the 2024-11-13 t-lang design meeting with feedback incorporated.

See this comment for the most recent summary of changes to this RFC since it was opened.

Rendered

@davidtwco davidtwco added the T-lang Relevant to the language team, which will review and decide on the RFC. label Nov 15, 2024
Co-authored-by: León Orell Valerian Liehr <[email protected]>
@tmandry tmandry added the I-lang-nominated Indicates that an issue has been nominated for prioritizing at the next lang team meeting. label Nov 15, 2024
@davidtwco
Copy link
Member Author

Pushed small updates following above comments and updated previous summary comment.

davidtwco added a commit to davidtwco/rust that referenced this pull request Feb 25, 2025
`rustc_codegen_llvm` relied on `Deref` impls where `Deref::Target` was
or contained an extern type - in my experimental implementation of
rust-lang/rfcs#3729, this isn't possible as the `Target` associated
type's `?Sized` bound cannot be relaxed backwards compatibly (unless we
coming up with some way of doing this).

In later pull requests with the rust-lang/rfcs#3729 implementation,
breakage like this could only occur for nightly users relying on the
`extern_types` feature.

Upstreaming this to avoid needing to keep carrying this patch locally,
and I think it'll necessarily need to change eventually.
davidtwco added a commit to davidtwco/rust that referenced this pull request Feb 25, 2025
`rustc_codegen_llvm` relied on `Deref` impls where `Deref::Target` was
or contained an extern type - in my experimental implementation of
rust-lang/rfcs#3729, this isn't possible as the `Target` associated
type's `?Sized` bound cannot be relaxed backwards compatibly (unless we
come up with some way of doing this).

In later pull requests with the rust-lang/rfcs#3729 implementation,
breakage like this could only occur for nightly users relying on the
`extern_types` feature.

Upstreaming this to avoid needing to keep carrying this patch locally,
and I think it'll necessarily need to change eventually.
davidtwco added a commit to davidtwco/rust that referenced this pull request Feb 25, 2025
`rustc_codegen_llvm` relied on `Deref` impls where `Deref::Target` was
or contained an extern type - in my experimental implementation of
rust-lang/rfcs#3729, this isn't possible as the `Target` associated
type's `?Sized` bound cannot be relaxed backwards compatibly (unless we
come up with some way of doing this).

In later pull requests with the rust-lang/rfcs#3729 implementation,
breakage like this could only occur for nightly users relying on the
`extern_types` feature.

Upstreaming this to avoid needing to keep carrying this patch locally,
and I think it'll necessarily need to change eventually.
fmease added a commit to fmease/rust that referenced this pull request Feb 26, 2025
…=lcnr

codegen_llvm: avoid `Deref` impls w/ extern type

`rustc_codegen_llvm` relied on `Deref` impls where `Deref::Target` was or contained an extern type - in my experimental implementation of rust-lang/rfcs#3729, this isn't possible as the `Target` associated type's `?Sized` bound cannot be relaxed backwards compatibly (unless we come up with some way of doing this).

In later pull requests with the rust-lang/rfcs#3729 implementation, breakage like this could only occur for nightly users relying on the `extern_types` feature.

Upstreaming this to avoid needing to keep carrying this patch locally, and I think it'll necessarily need to change eventually.
fmease added a commit to fmease/rust that referenced this pull request Feb 26, 2025
…, r=compiler-errors

trait_sel: resolve vars in host effects

In the standard library, the `Extend` impl for `Iterator` (specialised with `TrustedLen`) has a parameter which is constrained by a projection predicate. This projection predicate provides a value for an inference variable but - if the default bound is `const Sized` instead of `Sized` - host effect evaluation wasn't resolving variables first. Added a test that doesn't depend on a rust-lang/rfcs#3729 implementation.

Adding the extra resolve can the number of errors in some tests when they gain host effect predicates, but this is not unexpected as calls to `resolve_vars_if_possible` can cause more error tainting to happen.
fmease added a commit to fmease/rust that referenced this pull request Feb 26, 2025
…r=compiler-errors

hir_analysis: skip self type of host effect preds in variances_of

Discovered as part of an implementation of rust-lang/rfcs#3729 - w/out this then when introducing const trait bounds: many more interesting tests change with different output, missing errors, new errors, etc related to this but they all depend on feature flags and are much more complex than this test.

r? `@oli-obk`
fmease added a commit to fmease/rust that referenced this pull request Feb 26, 2025
…=lcnr

codegen_llvm: avoid `Deref` impls w/ extern type

`rustc_codegen_llvm` relied on `Deref` impls where `Deref::Target` was or contained an extern type - in my experimental implementation of rust-lang/rfcs#3729, this isn't possible as the `Target` associated type's `?Sized` bound cannot be relaxed backwards compatibly (unless we come up with some way of doing this).

In later pull requests with the rust-lang/rfcs#3729 implementation, breakage like this could only occur for nightly users relying on the `extern_types` feature.

Upstreaming this to avoid needing to keep carrying this patch locally, and I think it'll necessarily need to change eventually.
fmease added a commit to fmease/rust that referenced this pull request Feb 26, 2025
…, r=compiler-errors

trait_sel: resolve vars in host effects

In the standard library, the `Extend` impl for `Iterator` (specialised with `TrustedLen`) has a parameter which is constrained by a projection predicate. This projection predicate provides a value for an inference variable but - if the default bound is `const Sized` instead of `Sized` - host effect evaluation wasn't resolving variables first. Added a test that doesn't depend on a rust-lang/rfcs#3729 implementation.

Adding the extra resolve can the number of errors in some tests when they gain host effect predicates, but this is not unexpected as calls to `resolve_vars_if_possible` can cause more error tainting to happen.
fmease added a commit to fmease/rust that referenced this pull request Feb 26, 2025
…r=compiler-errors

hir_analysis: skip self type of host effect preds in variances_of

Discovered as part of an implementation of rust-lang/rfcs#3729 - w/out this then when introducing const trait bounds: many more interesting tests change with different output, missing errors, new errors, etc related to this but they all depend on feature flags and are much more complex than this test.

r? ``@oli-obk``
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 26, 2025
Rollup merge of rust-lang#137613 - davidtwco:const-traits-variances, r=compiler-errors

hir_analysis: skip self type of host effect preds in variances_of

Discovered as part of an implementation of rust-lang/rfcs#3729 - w/out this then when introducing const trait bounds: many more interesting tests change with different output, missing errors, new errors, etc related to this but they all depend on feature flags and are much more complex than this test.

r? ``@oli-obk``
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 26, 2025
Rollup merge of rust-lang#137604 - davidtwco:host-effect-resolve-vars, r=compiler-errors

trait_sel: resolve vars in host effects

In the standard library, the `Extend` impl for `Iterator` (specialised with `TrustedLen`) has a parameter which is constrained by a projection predicate. This projection predicate provides a value for an inference variable but - if the default bound is `const Sized` instead of `Sized` - host effect evaluation wasn't resolving variables first. Added a test that doesn't depend on a rust-lang/rfcs#3729 implementation.

Adding the extra resolve can the number of errors in some tests when they gain host effect predicates, but this is not unexpected as calls to `resolve_vars_if_possible` can cause more error tainting to happen.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 26, 2025
Rollup merge of rust-lang#137603 - davidtwco:extern-types-no-deref, r=lcnr

codegen_llvm: avoid `Deref` impls w/ extern type

`rustc_codegen_llvm` relied on `Deref` impls where `Deref::Target` was or contained an extern type - in my experimental implementation of rust-lang/rfcs#3729, this isn't possible as the `Target` associated type's `?Sized` bound cannot be relaxed backwards compatibly (unless we come up with some way of doing this).

In later pull requests with the rust-lang/rfcs#3729 implementation, breakage like this could only occur for nightly users relying on the `extern_types` feature.

Upstreaming this to avoid needing to keep carrying this patch locally, and I think it'll necessarily need to change eventually.
@lcnr lcnr added the T-types Relevant to the types team, which will review and decide on the RFC. label Feb 27, 2025
@davidtwco
Copy link
Member Author

An initial implementation of this is available at rust-lang/rust#137944

Comment on lines +1957 to +1958
- Allow `std::ptr::Pointee` to be implemented manually on user types, which would
replace the compiler's implementation.
Copy link
Contributor

Choose a reason for hiding this comment

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

normal auto traits (such as Send and Sync) can be explicitly implemented, the intent of this RFC seems to be that these new traits cannot be (similar to Sized). This should be explicitly noted.

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 12, 2025
Sized Hierarchy

This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.

RFC 3729 describes migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

- On the current edition, `Sized` is rewritten as `const Sized`
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted.
  - On the next edition, non-const `Sized` will resume being the default bound.
- On the current edition, `?Sized` is rewritten as `const MetaSized`
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted.
  - On the next edition, writing `?Sized` will be prohibited.
- On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted.
  - On the next edition, there is no default `const MetaSized` supertrait.

Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const MetaSized`) unless the `sized_hierarchy` feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

**Notes:**

- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
  - Each commit has a short description describing its purpose.
  - This patch is large but it's primarily in the test suite (library: +573/-184, compiler: +1268/-310, tests: +3720/-452).
- It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible.
  - I'd appreciate feedback on how best to go about this from those familiar with the type system.
- On my local machine, this passes all of the test suites, a stage two build and a tidy check.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.

Fixes rust-lang#79409.

r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 17, 2025
Sized Hierarchy

This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.

RFC 3729 describes migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

- On the current edition, `Sized` is rewritten as `const Sized`
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted.
  - On the next edition, non-const `Sized` will resume being the default bound.
- On the current edition, `?Sized` is rewritten as `const MetaSized`
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted.
  - On the next edition, writing `?Sized` will be prohibited.
- On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted.
  - On the next edition, there is no default `const MetaSized` supertrait.

Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const MetaSized`) unless the `sized_hierarchy` feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

**Notes:**

- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
  - Each commit has a short description describing its purpose.
  - This patch is large but it's primarily in the test suite (library: +573/-184, compiler: +1268/-310, tests: +3720/-452).
- It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible.
  - I'd appreciate feedback on how best to go about this from those familiar with the type system.
- On my local machine, this passes all of the test suites, a stage two build and a tidy check.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.

Fixes rust-lang#79409.

r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 18, 2025
Sized Hierarchy

This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.

RFC 3729 describes migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

- On the current edition, `Sized` is rewritten as `const Sized`
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted.
  - On the next edition, non-const `Sized` will resume being the default bound.
- On the current edition, `?Sized` is rewritten as `const MetaSized`
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted.
  - On the next edition, writing `?Sized` will be prohibited.
- On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted.
  - On the next edition, there is no default `const MetaSized` supertrait.

Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const MetaSized`) unless the `sized_hierarchy` feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

**Notes:**

- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
  - Each commit has a short description describing its purpose.
  - This patch is large but it's primarily in the test suite (library: +573/-184, compiler: +1268/-310, tests: +3720/-452).
- It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible.
  - I'd appreciate feedback on how best to go about this from those familiar with the type system.
- On my local machine, this passes all of the test suites, a stage two build and a tidy check.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)

Fixes rust-lang#79409.

r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 18, 2025
Sized Hierarchy

This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.

RFC 3729 describes migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

- On the current edition, `Sized` is rewritten as `const Sized`
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted.
  - On the next edition, non-const `Sized` will resume being the default bound.
- On the current edition, `?Sized` is rewritten as `const MetaSized`
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted.
  - On the next edition, writing `?Sized` will be prohibited.
- On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.
  - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted.
  - On the next edition, there is no default `const MetaSized` supertrait.

Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const MetaSized`) unless the `sized_hierarchy` feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

**Notes:**

- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
  - Each commit has a short description describing its purpose.
  - This patch is large but it's primarily in the test suite (library: +573/-184, compiler: +1268/-310, tests: +3720/-452).
- It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible.
  - I'd appreciate feedback on how best to go about this from those familiar with the type system.
- On my local machine, this passes all of the test suites, a stage two build and a tidy check.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)

Fixes rust-lang#79409.

r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dst Proposals re. DSTs I-lang-radar Items that are on lang's radar and will need eventual work or consideration. T-lang Relevant to the language team, which will review and decide on the RFC. T-types Relevant to the types team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.