Miri engine cleanup
* Unify the two maps in memory to store the allocation and its kind together.
* Share the handling of statics between CTFE and miri: The miri engine always
uses "lazy" `AllocType::Static` when encountering a static. Acessing that
static invokes CTFE (no matter the machine). The machine only has any
influence when writing to a static, which CTFE outright rejects (but miri
makes a copy-on-write).
* Add an `AllocId` to by-ref consts so miri can use them as operands without
making copies.
* Move responsibilities around for the `eval_fn_call` machine hook: The hook
just has to find the MIR (or entirely take care of everything); pushing the
new stack frame is taken care of by the miri engine.
* Expose the intrinsics and lang items implemented by CTFE so miri does not
have to reimplement them.
* Allow Machine to hook into foreign statics (used by miri to get rid of some other hacks).
* Clean up function calling.
* Switch const sanity check to work on operands, not mplaces.
* Move const_eval out of rustc_mir::interpret, to make sure that it does not access private implementation details.
In particular, we can finally make `eval_operand` take `&self`. :-)
Should be merged after https://github.com/rust-lang/rust/pull/53609, across which I will rebase.
add more Cortex-R targets
This expands on PR #53663 to complete the set of Cortex-R targets and builds
rust-std components for them.
r? @alexcrichton
each extra rust-std component (there's 4 of them) takes about 3 minutes to build
on my local machine. In terms of stability (LLVM codegen bugs) these new targets
should be as stable as the Cortex-M ones (e.g. `thumbv7m-none-eabi`).
If the extra build time is too much we can leave the rust-std components out for
now
closes#53663
cc @paoloteti
Restructure hir::map::Node and hir::map::Entry
- Moves `hir::map::Node` to `hir::Node` and removes the `Node*` prefix from its variants.
- Changes `hir::map::Entry` to a struct `hir::map::Entry`.
- Removes the `Node*` prefix from each of `AnnNode`s variants.
r? @eddyb
document the platform-specific behavior of Command::current_dir
See also https://github.com/rust-lang/rust/issues/37868.
Here's my initial wording:
> Note that if the program path is relative (e.g. `"./script.sh"`), the interaction between that path and `current_dir` varies across platforms. Windows currently ignores `current_dir` when locating the program, but Unix-like systems interpret the program path relative to `current_dir`. These implementation details aren't considered stable, and it's recommended to call `canonicalize` to get an absolute program path instead of using relative paths and `current_dir` together.
I'd like to get feedback on:
- _Should_ we consider those details stable? It might be disruptive to change them, regardless of what I can get away with claiming in docs :)
- Is `canonicalize` an appropriate recommendation? As discussed in #37868 above, there are reasons it's not called automatically in the `Command` implementation.
Warn on anon params in 2015 edition
cc #41686https://github.com/rust-lang/rfcs/pull/2522
cc @Centril @nikomatsakis
TODO:
- [x] Make sure the tests pass.
- [x] Make sure there is rustfix-able suggestion. Current plan is to just suggest `_ : Foo`
- [x] Add a rustfix ui test.
EDIT: It seems I already did the last two in #48309
move the Pin API into its own module for centralized documentation
This implements the change proposed by @withoutboats in #49150, as suggested by @RalfJung in the review of #53104,
along with the documentation that was originally in it, that was deemed more appropriate in module-level documentation.
r? @RalfJung
resolve suggestions should use `crate::` when enabled
I couldn't find a way to add a specific assertion for the ui test, so the expected output is living under the `crates-in-path.stderr` ui test.
- is this the right place for the test?
fixes#51212
