-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Guard against non-monomorphized type_id intrinsic call #74538
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
r? @lcnr (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you also add a test for type_name
?
Something like
#![feature(const_type_name)]
fn test<T: 'static>() {
let _ = [0; {
std::any::type_name::<T>();
7
}];
//~^ ERROR constant expression depends on a generic parameter
}
We also probably want a test using |
Added. |
Thanks @bors r+ rollup=always |
📌 Commit b3340b5 has been approved by |
Guard against non-monomorphized type_id intrinsic call This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected. Fixes rust-lang#73976
Guard against non-monomorphized type_id intrinsic call This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected. Fixes rust-lang#73976
Guard against non-monomorphized type_id intrinsic call This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected. Fixes rust-lang#73976
Guard against non-monomorphized type_id intrinsic call This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected. Fixes rust-lang#73976
Guard against non-monomorphized type_id intrinsic call This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected. Fixes rust-lang#73976
Guard against non-monomorphized type_id intrinsic call This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected. Fixes rust-lang#73976
…arth Rollup of 9 pull requests Successful merges: - rust-lang#73783 (Detect when `'static` obligation might come from an `impl`) - rust-lang#73868 (Advertise correct stable version for const control flow) - rust-lang#74460 (rustdoc: Always warn when linking from public to private items) - rust-lang#74538 (Guard against non-monomorphized type_id intrinsic call) - rust-lang#74541 (Add the aarch64-apple-darwin target ) - rust-lang#74600 (Enable perf try builder) - rust-lang#74618 (Do not ICE on assoc type with bad placeholder) - rust-lang#74631 (rustc_target: Add a target spec option for disabling `--eh-frame-hdr`) - rust-lang#74643 (build: Remove unnecessary `cargo:rerun-if-env-changed` annotations) Failed merges: r? @ghost
Improve diagnostics when constant pattern is too generic This PR is a follow-up to PR rust-lang#74538 and issue rust-lang#73976 When constants queries Layout, TypeId or type_name of a generic parameter, instead of emitting `could not evaluate constant pattern`, we will instead emit a more detailed message `constant pattern depends on a generic parameter`.
…li-obk make `ConstEvaluatable` more strict relevant zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/.60ConstEvaluatable.60.20generic.20functions/near/204125452 Let's see how much this impacts. Depending on how this goes this should probably be a future compat warning. Short explanation: we currently forbid anonymous constants which depend on generic types, e.g. `[0; std::mem::size_of::<T>]` currently errors. We previously checked this by evaluating the constant and returned an error if that failed. This however allows things like ```rust const fn foo<T>() -> usize { if std::mem::size_of::<*mut T>() < 8 { // size of *mut T does not depend on T std::mem::size_of::<T>() } else { 8 } } fn test<T>() { let _ = [0; foo::<T>()]; } ``` which is a backwards compatibility hazard. This also has worrying interactions with mir optimizations (rust-lang#74491 (comment)) and intrinsics (rust-lang#74538). r? `@oli-obk` `@eddyb`
This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected.
Fixes #73976