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

Age	Commit message (Collapse)	Author	Lines
2021-02-16	Pass PlaceTy by reference not value	Tomasz Miąsko	-6/+6

2021-02-16	Pass OpTy by reference not value	Tomasz Miąsko	-2/+2

2021-01-12	Auto merge of #78407 - oli-obk:ub_checkable_ctfe, r=RalfJung,pnkfelix	bors	-0/+10
	Make CTFE able to check for UB... ... by not doing any optimizations on the `const fn` MIR used in CTFE. This means we duplicate all `const fn`'s MIR now, once for CTFE, once for runtime. This PR is for checking the perf effect, so we have some data when talking about https://github.com/rust-lang/const-eval/blob/master/rfcs/0000-const-ub.md To do this, we now have two queries for obtaining mir: `optimized_mir` and `mir_for_ctfe`. It is now illegal to invoke `optimized_mir` to obtain the MIR of a const/static item's initializer, an array length, an inline const expression or an enum discriminant initializer. For `const fn`, both `optimized_mir` and `mir_for_ctfe` work, the former returning the MIR that LLVM should use if the function is called at runtime. Similarly it is illegal to invoke `mir_for_ctfe` on regular functions. This is all checked via appropriate assertions and I don't think it is easy to get wrong, as there should be no `mir_for_ctfe` calls outside the const evaluator or metadata encoding. Almost all rustc devs should keep using `optimized_mir` (or `instance_mir` for that matter).
2021-01-10	Add ABI argument to `find_mir_or_eval_fn`	Nym Seddon	-0/+4
	Add ABI argument for called function in `find_mir_or_eval_fn` and `call_extra_fn`. Useful for comparing with expected ABI in interpreters. Related to [miri/1631](https://github.com/rust-lang/miri/issues/1631)
2021-01-04	Move MIR body loading to a machine function	oli	-0/+10

2020-12-11	Fix rustfmt failure	JCTyblaidd	-1/+1

2020-12-11	Add post-initialization hook for static memory initialized using the ↵	JCTyblaidd	-0/+10
	interpereter.
2020-12-10	Auto merge of #79621 - usbalbin:constier_maybe_uninit, r=RalfJung	bors	-1/+1
	Constier maybe uninit I was playing around trying to make `[T; N]::zip()` in #79451 be `const fn`. One of the things I bumped into was `MaybeUninit::assume_init`. Is there any reason for the intrinsic `assert_inhabited<T>()` and therefore `MaybeUninit::assume_init` not being `const`? --- I have as best as I could tried to follow the instruction in [library/core/src/intrinsics.rs](https://github.com/rust-lang/rust/blob/master/library/core/src/intrinsics.rs#L11). I have no idea what I am doing but it seems to compile after some slight changes after the copy paste. Is this anywhere near how this should be done? Also any ideas for name of the feature gate? I guess `const_maybe_assume_init` is quite misleading since I have added some more methods. Should I add test? If so what should be tested?
2020-12-06	Fix comments related to abort()	Albin Hedman	-4/+2

2020-12-05	abort() now takes a msg parameter	Albin Hedman	-2/+4

2020-12-03	move interpret::MemoryKind::Heap to const eval	Vishnunarayan K I	-4/+4

2020-10-13	Replace absolute paths with relative ones	est31	-3/+4
	Modern compilers allow reaching external crates like std or core via relative paths in modules outside of lib.rs and main.rs.
2020-08-30	mv compiler to compiler/	mark	-0/+422