-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Treat safe target_feature functions as unsafe by default [less invasive variant] #134353
Treat safe target_feature functions as unsafe by default [less invasive variant] #134353
Conversation
r? @chenyukang rustbot has assigned @chenyukang. Use |
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
This comment has been minimized.
This comment has been minimized.
9bd90ce
to
273c6c5
Compare
…ler-errors Handle fndef rendering together with signature rendering Pulled out of rust-lang#134353 Changes some highlighting in type mismatch errors around fndefs
…ler-errors Handle fndef rendering together with signature rendering Pulled out of rust-lang#134353 Changes some highlighting in type mismatch errors around fndefs
…ler-errors Handle fndef rendering together with signature rendering Pulled out of rust-lang#134353 Changes some highlighting in type mismatch errors around fndefs
273c6c5
to
e14cb3b
Compare
This comment has been minimized.
This comment has been minimized.
e14cb3b
to
97754d0
Compare
Some changes occurred in need_type_info.rs cc @lcnr |
This comment has been minimized.
This comment has been minimized.
…ostic-cleanups, r=compiler-errors Some trait method vs impl method signature difference diagnostic cleanups Just some things I noticed while debugging a weird diagnostic in rust-lang#134353 best reviewed commit by commit
…ostic-cleanups, r=compiler-errors Some trait method vs impl method signature difference diagnostic cleanups Just some things I noticed while debugging a weird diagnostic in rust-lang#134353 best reviewed commit by commit
…ostic-cleanups, r=compiler-errors Some trait method vs impl method signature difference diagnostic cleanups Just some things I noticed while debugging a weird diagnostic in rust-lang#134353 best reviewed commit by commit
…ostic-cleanups, r=compiler-errors Some trait method vs impl method signature difference diagnostic cleanups Just some things I noticed while debugging a weird diagnostic in rust-lang#134353 best reviewed commit by commit
Rollup merge of rust-lang#134386 - oli-obk:some-trait-impl-diff-diagnostic-cleanups, r=compiler-errors Some trait method vs impl method signature difference diagnostic cleanups Just some things I noticed while debugging a weird diagnostic in rust-lang#134353 best reviewed commit by commit
…ler-errors Handle fndef rendering together with signature rendering Pulled out of rust-lang#134353 Changes some highlighting in type mismatch errors around fndefs
…ler-errors Handle fndef rendering together with signature rendering Pulled out of rust-lang#134353 Changes some highlighting in type mismatch errors around fndefs
97754d0
to
54901b6
Compare
This comment has been minimized.
This comment has been minimized.
Rollup merge of rust-lang#134354 - oli-obk:push-nlrxswvpqnuk, r=compiler-errors Handle fndef rendering together with signature rendering Pulled out of rust-lang#134353 Changes some highlighting in type mismatch errors around fndefs
…-by-default, r=wesleywiser Treat safe target_feature functions as unsafe by default [less invasive variant] This unblocks * rust-lang#134090 As I stated in rust-lang#134090 (comment) I think the previous impl was too easy to get wrong, as by default it treated safe target feature functions as safe and had to add additional checks for when they weren't. Now the logic is inverted. By default they are unsafe and you have to explicitly handle safe target feature functions. This is the less (imo) invasive variant of rust-lang#134317, as it doesn't require changing the Safety enum, so it only affects FnDefs and nothing else, as it should.
…llaumeGomez Rollup of 5 pull requests Successful merges: - rust-lang#134216 (Enable "jump to def" feature on patterns) - rust-lang#134353 (Treat safe target_feature functions as unsafe by default [less invasive variant]) - rust-lang#134880 (Made `Path::name` only have item name rather than full name) - rust-lang#135466 (Leak check in `impossible_predicates` to avoid monomorphizing impossible instances) - rust-lang#135476 (Remove remnant of asmjs) r? `@ghost` `@rustbot` modify labels: rollup
b1deae5
to
767d4fe
Compare
@bors r+ rollup=iffy |
@bors r=wesleywiser |
💡 This pull request was already approved, no need to approve it again.
|
☀️ Test successful - checks-actions |
Finished benchmarking commit (341f603): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -3.1%, secondary 0.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 7.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary 0.0%, secondary 0.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 764.012s -> 762.915s (-0.14%) |
…-ptr, r=oli-obk Allow coercing safe-to-call target_feature functions to safe fn pointers r? oli-obk `@oli-obk:` this is based on your PR rust-lang#134353 :-) See rust-lang#134090 (comment) for the motivation behind this change.
Rollup merge of rust-lang#135504 - veluca93:target-feature-cast-to-fn-ptr, r=oli-obk Allow coercing safe-to-call target_feature functions to safe fn pointers r? oli-obk `@oli-obk:` this is based on your PR rust-lang#134353 :-) See rust-lang#134090 (comment) for the motivation behind this change.
This unblocks
As I stated in #134090 (comment) I think the previous impl was too easy to get wrong, as by default it treated safe target feature functions as safe and had to add additional checks for when they weren't. Now the logic is inverted. By default they are unsafe and you have to explicitly handle safe target feature functions.
This is the less (imo) invasive variant of #134317, as it doesn't require changing the Safety enum, so it only affects FnDefs and nothing else, as it should.