https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=auto 2023-01-11T09:32:08+00:00 2023-01-11T09:32:08+00:00 Albert Larsan 74931857+albertlarsan68@users.noreply.github.com 2023-01-05T08:13:28+00:00 urn:sha1:cf2dff2b1e3fa55fa5415d524200070d0d7aacfe 2023-01-09T15:35:27+00:00 fee1-dead ent3rm4n@gmail.com 2023-01-09T15:35:27+00:00 urn:sha1:63f2a13855a4b81989f43e8001c1a0ea64c0090f Fix ui constant tests for big-endian platforms A number of tests under ui/const-ptr and ui/consts are currently failing on big-endian platforms as the binary encoding of some constants is hard-coded in the stderr test files. Fix this by a combination of two types of changes: - Where possible (i.e. where the particular value of a constant does not affect the purpose of the test), choose constant values that have the same encoding on big- and little-endian platforms. - Where this is not possible, provide a normalize-stderr-test rule that transforms the printed big-endian encoding of such constants into the corresponding little-endian form. Fixes part of https://github.com/rust-lang/rust/issues/105383. 2023-01-07T16:13:18+00:00 bors bors@rust-lang.org 2023-01-07T16:13:18+00:00 urn:sha1:b1691f6413a4afd7529ab309965123cc63e82021 Perform SimplifyLocals before ConstProp. MIR before `ConstProp` may have a lot of dead writes, this makes `ConstProp` do unnecessary work. r? `@ghost` 2023-01-06T12:55:23+00:00 Takayuki Maeda takoyaki0316@gmail.com 2023-01-06T11:55:10+00:00 urn:sha1:804dea9ca6a02baedb1efc639b848fa080dbf51d fix rustdoc ui test 2022-12-27T14:23:15+00:00 Ulrich Weigand ulrich.weigand@de.ibm.com 2022-12-22T15:40:50+00:00 urn:sha1:73e7207bfc0dc47f7b54c81c0d2351387ef708fb A number of tests under ui/const-ptr and ui/consts are currently failing on big-endian platforms as the binary encoding of some constants is hard-coded in the stderr test files. Fix this by providing a normalize-stderr-test rule that strips out the raw bytes hex dump, so the comparison can be done in an endianness-independent manner. Note that in most cases, this means the tests are now also independent of word size, so the 32bit and 64bit cases can be re-unified. To keep tests that verify the details of those raw bytes dumps, a new test case raw-bytes.rs performs the tests where the hex dumps were stripped out a second time, but only on little- endian platforms. In addition, src/test/ui/const-ptr/forbidden_slices.rs exposes an endian-specific difference in this diagnostic output: constructing invalid value at .<deref>[0]: encountered 0x11, but expected a boolean depending on which byte of D0 is not a boolean value (0 or 1). Fixed this by choosing a value of D0 that differs from 0 or 1 in all bytes. Fixes part of https://github.com/rust-lang/rust/issues/105383. 2022-12-25T18:01:07+00:00 Camille GILLOT gillot.camille@gmail.com 2022-12-04T19:20:55+00:00 urn:sha1:028b4745f4db7297c5082caabff986a477662375 2022-12-24T14:00:37+00:00 bors bors@rust-lang.org 2022-12-24T14:00:37+00:00 urn:sha1:f5c3dfdbbf06d5997079ac7339de5002f7ced2a3 Stop promoting all the things fixes #91009 r? `@RalfJung` 2022-12-22T18:36:13+00:00 Matthias Krüger matthias.krueger@famsik.de 2022-12-22T18:36:13+00:00 urn:sha1:548d49c7897e91ff6f703c00b3a2ff269b894fdc Ensure param-env is const before calling `eval_to_valtree` Other queries call `ParamEnv::with_const` *inside* of the query itself (e.g. `const_eval_global_id_for_typeck`), so this could alternatively be moved into the provider of `eval_to_valtree` instead. I don't have a particularly strong opinion, though *theoretically* caching is better if we make the query keys more constrained. I'm not exactly sure how this is an effect of the `-Zmir-opt-level=3` flag. Maybe something about the inliner causes us to inline an unevaluated const into a body where it can be evaluated, but where it has not yet been normalized. This seems likely, since we're inlining `from_fn_1::<{ N / 2 }, _>` in `from_fn_2`, which means that we will need to evaluate that constant during the const prop pass after inlining. Fixes #104396 2022-12-21T23:20:04+00:00 bors bors@rust-lang.org 2022-12-21T23:20:04+00:00 urn:sha1:bdbe392a13bc9782b98de193c3751b9d96bb5fcc Rename `assert_uninit_valid` intrinsic It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that. This is actually not fully correct though, as it does still panic for all uninit with `-Zstrict-init-checks`. I'm not sure what the best way is to deal with that not causing confusion. I guess we could just remove the flag? I don't think having it makes a lot of sense anymore with the direction that we have chose to go. It could be relevant again if #100423 lands so removing it may be a bit over eager. r? `@RalfJung` 2022-12-17T22:33:06+00:00 Michael Goulet michael@errs.io 2022-12-17T22:32:57+00:00 urn:sha1:c1181e12243f078b1cc562249569e6766d90f8f6