rust - https://github.com/rust-lang/rust

Age	Commit message (Collapse)	Author	Lines
2023-07-27	CHECK only for opaque ptr	Josh Stone	-2/+2

2023-05-22	drop-in-place-noalias test: needs -O to ensure attributes are added on nopt ↵	Erik Desjardins	-1/+1
	builders
2023-05-20	ensure !Unpin types do not get noalias	Erik Desjardins	-19/+23

2023-05-20	Apply `noalias`, `nonnull`, `dereferenceable`, and `align` attributes ↵	Patrick Walton	-1/+1
	unconditionally. 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.
2023-05-20	[rustc_ty_utils] Add the LLVM `noalias` parameter attribute to ↵	Patrick Walton	-0/+34
	`drop_in_place` in certain cases. 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.