resolve: prohibit anon const non-static lifetimes
Fixes#75323, fixes#74447 and fixes#73375.
This PR prohibits non-static lifetimes in anonymous constants when only the `min_const_generics` feature is enabled. ~~To do so, `to_region_vid`'s `bug!` had to be changed into a delayed bug, which unfortunately required providing it a `TyCtxt`.~~
---
~~While I am happy with how the implementation of the error turned out in `rustc_passes::check_const`, emitting an error wasn't sufficient to avoid hitting the ICE later. I also tried implementing the error in `rustc_mir::transform::check_consts::validation` and that worked, but it didn't silence the ICE either. To silence the ICE, I changed it to a delayed bug which worked but was more invasive that I would have liked, and required I return an incorrect lifetime. It's possible that this check should be implemented earlier in the compiler to make the invasive changes unnecessary, but I wasn't sure where that would be and wanted to get some feedback first.~~
The approach taken by this PR has been changed to implement the error in name resolution, which ended up being much simpler.
cc @rust-lang/wg-const-eval
r? @lcnr
-Zvalidate-mir: Assert that storage is allocated on local use
This extends the MIR validator to check that locals are only used when their backing storage is currently allocated via `StorageLive`.
The result of this is that miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs.
The PR currently fails tests because miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs.
I have confirmed that tests pass (even with `-Zvalidate-mir`) once `SimplifyArmIdentity` is turned into a no-op (except mir-opt tests, of course).
This commit modifies name resolution to emit an error when non-static
lifetimes are used in anonymous constants when the `min_const_generics`
feature is enabled.
Signed-off-by: David Wood <david@davidtw.co>
Disable the SimplifyArmIdentity mir-opt
The optimization still has some bugs that need to be worked out
such as #77359.
We can try re-enabling this again after the known issues are resolved.
r? `@oli-obk`
Add accessors to Command.
This adds some accessor methods to `Command` to provide a way to access the values set when building the `Command`. An example where this can be useful is to display the command to be executed. This is roughly based on the [`ProcessBuilder`](13b73cdaf7/src/cargo/util/process_builder.rs (L105-L134)) in Cargo.
Possible concerns about the API:
- Values with NULs on Unix will be returned as `"<string-with-nul>"`. I don't think it is practical to avoid this, since otherwise a whole separate copy of all the values would need to be kept in `Command`.
- Does not handle `arg0` on Unix. This can be awkward to support in `get_args` and is rarely used. I figure if someone really wants it, it can be added to `CommandExt` as a separate method.
- Does not offer a way to detect `env_clear`. I'm uncertain if it would be useful for anyone.
- Does not offer a way to get an environment variable by name (`get_env`). I figure this can be added later if anyone really wants it. I think the motivation for this is weak, though. Also, the API could be a little awkward (return a `Option<Option<&OsStr>>`?).
- `get_envs` could skip "cleared" entries and just return `&OsStr` values instead of `Option<&OsStr>`. I'm on the fence here. My use case is to display a shell command, and I only intend it to be roughly equivalent to the actual execution, and I probably won't display `None` entries. I erred on the side of providing extra information, but I suspect many situations will just filter out the `None`s.
- Could implement more iterator stuff (like `DoubleEndedIterator`).
I have not implemented new std items before, so I'm uncertain if the existing issue should be reused, or if a new tracking issue is needed.
cc #44434
Related: https://github.com/rust-lang/rust/issues/66741
Guarded with `#![feature(default_alloc_error_handler)]` a default
`alloc_error_handler` is called, if a custom allocator is used and no
other custom `#[alloc_error_handler]` is defined.
The panic message does not contain the size anymore, because it would
pull in the fmt machinery, which would blow up the code size
significantly.
Rollup of 11 pull requests
Successful merges:
- #76851 (Fix 'FIXME' about using NonZeroU32 instead of u32.)
- #76979 (Improve std::sys::windows::compat)
- #77111 (Stabilize slice_ptr_range.)
- #77147 (Split sys_common::Mutex in StaticMutex and MovableMutex.)
- #77312 (Remove outdated line from `publish_toolstate` hook)
- #77362 (Fix is_absolute on WASI)
- #77375 (rustc_metadata: Do not forget to encode inherent impls for foreign types)
- #77385 (Improve the example for ptr::copy)
- #77389 (Fix some clippy lints)
- #77399 (BTreeMap: use Unique::from to avoid a cast where type information exists)
- #77429 (Link `new` method in `DefautHasher`s doc)
Failed merges:
r? `@ghost`
rustc_metadata: Do not forget to encode inherent impls for foreign types
So I tried to move FFI interface for LLVM from `rustc_codegen_llvm` to `rustc_llvm` and immediately encountered this fascinating issue.
Fixes https://github.com/rust-lang/rust/issues/46665.
Fix is_absolute on WASI
WASI does not match `cfg(unix)`, but its paths are Unix-like (`/some/path`) and don't have Windows-like prefixes.
Without this change, `is_absolute` for any paths, including `/some/path`, was returning `false`on a WASI target, which is obviously not true and undesirable.
Remove outdated line from `publish_toolstate` hook
We no longer add `I-nominated` to toolstate failure issues since T-compiler changed its meeting preparation workflow.
