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.

Sign up for GitHub

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

Jump to bottom

unnormalized user annotations can be ill-formed #104764

Closed
aliemjay opened this issue Nov 23, 2022 · 0 comments · Fixed by #120019
Closed

unnormalized user annotations can be ill-formed #104764

aliemjay opened this issue Nov 23, 2022 · 0 comments · Fixed by #120019
Assignees
@aliemjay
Labels
A-borrow-checker Area: The borrow checker A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. NLL-sound Working towards the "invalid code does not compile" goal T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@aliemjay
Copy link
Member

aliemjay commented Nov 23, 2022 •
edited by rustbot
Loading

We're still not doing WF-checks on user annotations prior to normalization, so this code is still accepted:

trait Trait { type Ty; }
impl<T> Trait for T { type Ty = (); }
fn test<T>() {
    let _: <&'static T as Trait>::Ty = ();
}

I consider this a different issue than #101350 because it is a more long-standing problem and not strictly an NLL regression.

Originally posted by @aliemjay in #101947 (comment)

@rustbot label C-bug T-types A-borrow-checker A-NLL NLL-sound
@rustbot claim
@rustbot rustbot added A-borrow-checker Area: The borrow checker A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. NLL-sound Working towards the "invalid code does not compile" goal T-types Relevant to the types team, which will review and decide on the PR/issue. labels Nov 23, 2022
@aliemjay aliemjay mentioned this issue Nov 23, 2022
Closed
This was referenced Nov 7, 2023
Draft
Closed
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 20, 2023
@bors
Auto merge of rust-lang#104098 - aliemjay:fn-wf, r=<try>
66ac3f1 
fix fn/const items implied bounds and wf check

These are two distinct changes (edit: actually three, see below):
1. Wf-check all fn item args. This is a soundness fix.
Fixes rust-lang#104005

2. Use implied bounds from impl header in borrowck of associated functions/consts. This strictly accepts more code and helps to mitigate the impact of other breaking changes.
Fixes rust-lang#98852
Fixes rust-lang#102611

The first is a breaking change and will likely have a big impact without the the second one. See the first commit for how it breaks libstd.

Landing the second one without the first will allow more incorrect code to pass. For example an exploit of rust-lang#104005 would be as simple as:
```rust
use core::fmt::Display;

trait ExtendLt<Witness> {
    fn extend(self) -> Box<dyn Display>;
}

impl<T: Display> ExtendLt<&'static T> for T {
    fn extend(self) -> Box<dyn Display> {
        Box::new(self)
    }
}

fn main() {
    let val = (&String::new()).extend();
    println!("{val}");
}
```

The third change is to to check WF of user type annotations before normalizing them (fixes rust-lang#104764, fixes rust-lang#104763). It is mutually dependent on the second change above: an attempt to land it separately in rust-lang#104746 caused several crater regressions that can all be mitigated by using the implied from the impl header. It is also necessary for the soundness of associated consts that use the implied bounds of impl header. See rust-lang#104763 and how the third commit fixes the soundness issue in `tests/ui/wf/wf-associated-const.rs` that was introduces by the previous commit.

cc `@lcnr`
r? types
@lcnr lcnr mentioned this issue Jan 16, 2024
Merged
@bors bors closed this as completed in 6bf600b Jan 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@aliemjay aliemjay

Labels
A-borrow-checker Area: The borrow checker A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. NLL-sound Working towards the "invalid code does not compile" goal T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
2 participants
@aliemjay @rustbot