-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Normalization can skip WF #100041
Comments
cc @rust-lang/types |
@rustbot label +T-types |
I think I found the bug(s). This is:
Let me put up a PR. |
Is this fixed in #99217? |
Just checked out that PR, and it's not fixed by #99217. |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-high |
Status: still happens. #100046 is blocked on implied bounds for unnormalized types. |
…unsound-issues, r=jackh726 Add `known-bug` tests for 11 unsound issues r? `@jackh726` Should tests for other issues be in separate PRs? Thanks. Edit: Partially addresses rust-lang#105107. This PR adds `known-bug` tests for 11 unsound issues: - rust-lang#25860 - rust-lang#49206 - rust-lang#57893 - rust-lang#84366 - rust-lang#84533 - rust-lang#84591 - rust-lang#85099 - rust-lang#98117 - rust-lang#100041 - rust-lang#100051 - rust-lang#104005
…unsound-issues, r=jackh726 Add `known-bug` tests for 11 unsound issues r? ``@jackh726`` Should tests for other issues be in separate PRs? Thanks. Edit: Partially addresses rust-lang#105107. This PR adds `known-bug` tests for 11 unsound issues: - rust-lang#25860 - rust-lang#49206 - rust-lang#57893 - rust-lang#84366 - rust-lang#84533 - rust-lang#84591 - rust-lang#85099 - rust-lang#98117 - rust-lang#100041 - rust-lang#100051 - rust-lang#104005
…unsound-issues, r=jackh726 Add `known-bug` tests for 11 unsound issues r? `@jackh726` Should tests for other issues be in separate PRs? Thanks. Edit: Partially addresses rust-lang#105107. This PR adds `known-bug` tests for 11 unsound issues: - rust-lang#25860 - rust-lang#49206 - rust-lang#57893 - rust-lang#84366 - rust-lang#84533 - rust-lang#84591 - rust-lang#85099 - rust-lang#98117 - rust-lang#100041 - rust-lang#100051 - rust-lang#104005
…unsound-issues, r=jackh726 Add `known-bug` tests for 11 unsound issues r? ``@jackh726`` Should tests for other issues be in separate PRs? Thanks. Edit: Partially addresses rust-lang#105107. This PR adds `known-bug` tests for 11 unsound issues: - rust-lang#25860 - rust-lang#49206 - rust-lang#57893 - rust-lang#84366 - rust-lang#84533 - rust-lang#84591 - rust-lang#85099 - rust-lang#98117 - rust-lang#100041 - rust-lang#100051 - rust-lang#104005
…unsound-issues, r=jackh726 Add `known-bug` tests for 11 unsound issues r? `@jackh726` Should tests for other issues be in separate PRs? Thanks. Edit: Partially addresses rust-lang#105107. This PR adds `known-bug` tests for 11 unsound issues: - rust-lang#25860 - rust-lang#49206 - rust-lang#57893 - rust-lang#84366 - rust-lang#84533 - rust-lang#84591 - rust-lang#85099 - rust-lang#98117 - rust-lang#100041 - rust-lang#100051 - rust-lang#104005
…unsound-issues, r=jackh726 Add `known-bug` tests for 11 unsound issues r? ``@jackh726`` Should tests for other issues be in separate PRs? Thanks. Edit: Partially addresses rust-lang#105107. This PR adds `known-bug` tests for 11 unsound issues: - rust-lang#25860 - rust-lang#49206 - rust-lang#57893 - rust-lang#84366 - rust-lang#84533 - rust-lang#84591 - rust-lang#85099 - rust-lang#98117 - rust-lang#100041 - rust-lang#100051 - rust-lang#104005
@rustbot label +I-ICE I turned this into an ICE: pub trait WellUnformed {
type RequestNormalize;
}
impl<T: ?Sized> WellUnformed for T {
type RequestNormalize = ();
}
pub fn latent(_: &[<[[()]] as WellUnformed>::RequestNormalize; 0]) {}
pub fn bang() {
latent(&[]);
}
Strangely enough, |
lol, given the ICE message I thought it was a side-effect of #111918, but it ICEs on stable as well. --- well, better an ICE than unsoundness, eh? |
…-rendering, r=GuillaumeGomez rustdoc: fix and refactor HTML rendering a bit * refactoring: get rid of a bunch of manual `f.alternate()` branches * not sure why this wasn't done so already, is this perf-sensitive? * fix an ICE in debug builds of rustdoc * rustdoc used to crash on empty outlives-bounds: `where 'a:` * properly escape const generic defaults * actually print empty trait and outlives-bounds (doesn't work for cross-crate reexports yet, will fix that at some other point) since they can have semantic significance * outlives-bounds: forces lifetime params to be early-bound instead of late-bound which is technically speaking part of the public API * trait-bounds: can affect the well-formedness, consider * makeshift “const-evaluatable” bounds under `generic_const_exprs` * bounds to force wf-checking in light of rust-lang#100041 (quite artificial I know, I couldn't figure out something better), see rust-lang#121160 (comment)
…-rendering, r=GuillaumeGomez rustdoc: fix and refactor HTML rendering a bit * refactoring: get rid of a bunch of manual `f.alternate()` branches * not sure why this wasn't done so already, is this perf-sensitive? * fix an ICE in debug builds of rustdoc * rustdoc used to crash on empty outlives-bounds: `where 'a:` * properly escape const generic defaults * actually print empty trait and outlives-bounds (doesn't work for cross-crate reexports yet, will fix that at some other point) since they can have semantic significance * outlives-bounds: forces lifetime params to be early-bound instead of late-bound which is technically speaking part of the public API * trait-bounds: can affect the well-formedness, consider * makeshift “const-evaluatable” bounds under `generic_const_exprs` * bounds to force wf-checking in light of rust-lang#100041 (quite artificial I know, I couldn't figure out something better), see rust-lang#121160 (comment)
Rollup merge of rust-lang#121160 - fmease:rustdoc-fix-n-refactor-html-rendering, r=GuillaumeGomez rustdoc: fix and refactor HTML rendering a bit * refactoring: get rid of a bunch of manual `f.alternate()` branches * not sure why this wasn't done so already, is this perf-sensitive? * fix an ICE in debug builds of rustdoc * rustdoc used to crash on empty outlives-bounds: `where 'a:` * properly escape const generic defaults * actually print empty trait and outlives-bounds (doesn't work for cross-crate reexports yet, will fix that at some other point) since they can have semantic significance * outlives-bounds: forces lifetime params to be early-bound instead of late-bound which is technically speaking part of the public API * trait-bounds: can affect the well-formedness, consider * makeshift “const-evaluatable” bounds under `generic_const_exprs` * bounds to force wf-checking in light of rust-lang#100041 (quite artificial I know, I couldn't figure out something better), see rust-lang#121160 (comment)
This is currently mostly fixable, except for types in impl headers. As stated by @aliemjay in #100046 (comment), we can check unnormalized types for WF if the type is from an item signature. We already use their unnormalized type when computing WF in borrowck, so we can first fix #105948 by using the unnormalized types from fn sigs. We can then check the wf of function signatures without normalizing them. |
lowering this from P-high to P-medium as this cannot directly result in undefined runtime behavior by itself. Fixing this will be straightforward once we've imnplemented the better approach to handling implied bounds on binders, which is still a high priority as it also blocks other issues, such as #25860 and #84591. |
I tried this code: [playground]
I expected this to error;
[[[[[[u8]]]]]]
is clearly not a well-formed type, asVec<str>
is perhaps even more cursed.Instead: it compiles.
This is especially relevant for blanket/builtin traits which have associated types, such as
marker::DiscriminantKind
andptr::Pointee
.Meta
1.64.0-nightly (2022-07-31 f9cba63)
@rustbot label +A-associated-items
cc @eddyb who said this was
@rustbot label +I-unsound
The text was updated successfully, but these errors were encountered: