rust/compiler/rustc_ty_utils/src, branch 1.71.0https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.71.02023-05-20T23:34:31+00:00ensure !Unpin types do not get noalias2023-05-20T23:34:31+00:00Erik Desjardinserikdesjardins@users.noreply.github.com2023-05-20T23:34:31+00:00urn:sha1:644818351b95c7a50eb05d73164cc6f4480ce9e7improve code checking for drop_in_place lang item2023-05-20T22:12:54+00:00Erik Desjardinserikdesjardins@users.noreply.github.com2023-05-20T21:54:31+00:00urn:sha1:47444d7c2559f4a82ec2d5ca65d86ad795e48aefApply `noalias`, `nonnull`, `dereferenceable`, and `align` attributes unconditionally.2023-05-20T22:12:54+00:00Patrick Waltonpcwalton@fb.com2022-11-17T23:24:39+00:00urn:sha1:21b8815b6cd74d307ebbdef7cf8c6de6b486c706
We've done measurements with Miri and have determined that `noalias` shouldn't
break code. The requirements that allow us to add dereferenceable and align
have been long documented in the standard library documentation.
[rustc_ty_utils] Add the LLVM `noalias` parameter attribute to `drop_in_place` in certain cases.2023-05-20T22:12:53+00:00Patrick Waltonpcwalton@fb.com2022-10-26T22:12:19+00:00urn:sha1:f71741bac41a5373791958d4a0a36c84d83b1bd5
LLVM can make use of the `noalias` parameter attribute on the parameter to
`drop_in_place` in areas like argument promotion. Because the Rust compiler
fully controls the code for `drop_in_place`, it can soundly deduce parameter
attributes on it. In the case of a value that has a programmer-defined Drop
implementation, we know that the first thing `drop_in_place` will do is pass a
pointer to the object to `Drop::drop`. `Drop::drop` takes `&mut`, so it must be
guaranteed that there are no pointers to the object upon entering that
function. Therefore, it should be safe to mark `noalias` there.
With this patch, we mark `noalias` only when the type is a value with a
programmer-defined Drop implementation. This is possibly overly conservative,
but I thought that proceeding cautiously was best in this instance.
Rollup merge of #111578 - Zoxc:query-macro-move, r=cjgillot2023-05-15T15:12:46+00:00Matthias Krügermatthias.krueger@famsik.de2023-05-15T15:12:46+00:00urn:sha1:2f0b456903c314601815685e56a3e83cf4444f36
Move expansion of query macros in rustc_middle to rustc_middle::query
This moves the expansion of `define_callbacks!` and `define_feedable!` from `rustc_middle::ty::query` to `rustc_middle::query`.
This means that types used in queries are both imported and used in `rustc_middle::query` instead of being split between these modules. It also decouples `rustc_middle::ty::query` further from `rustc_middle` which is helpful since we want to move `rustc_middle::ty::query` to the query system crates.
Move expansion of query macros in rustc_middle to rustc_middle::query2023-05-15T06:49:13+00:00John Kåre Alsakerjohn.kare.alsaker@gmail.com2023-05-15T04:24:45+00:00urn:sha1:fff20a703db364d8b91c14cef4779f5e632df191Auto merge of #111570 - compiler-errors:ct-err, r=BoxyUwU2023-05-15T01:03:29+00:00borsbors@rust-lang.org2023-05-15T01:03:29+00:00urn:sha1:8d18c32b61476ed16dd15074e71be3970368d6d7
Rename const error methods for consistency
renames `ty::Const`'s methods for creating a `ConstKind::Error` to be in the same naming style as `ty::Ty`'s equivalent methods.
r? `@BoxyUwU`
Rename const error methods for consistency2023-05-14T20:32:51+00:00Michael Gouletmichael@errs.io2023-05-14T20:32:46+00:00urn:sha1:8e163f9dce5da0c8badc365bba85b85b93850517Use the opaque_types_defined_by query to cheaply check for whether a hidden type may be registered for an opaque type2023-05-12T10:26:50+00:00Oli Scherergit-spam-no-reply9815368754983@oli-obk.de2023-04-25T08:07:44+00:00urn:sha1:4e92f761fe54fc602ec2bf63819e8c973d1facd5add `query opaque_types_defined_by`2023-05-12T10:26:07+00:00lcnrrust@lcnr.de2023-04-18T14:09:48+00:00urn:sha1:6ae803eedfeb57944cd0d2930d9a8b7a606baf4a