Add `-Zmiri-env-set` to set environment variables without modifying the host environment
This option allows to pass environment variables to the interpreted program without needing to modify the host environment (which may have undesired effects in some cases).
Add simple async drop glue generation
This is a prototype of the async drop glue generation for some simple types. Async drop glue is intended to behave very similar to the regular drop glue except for being asynchronous. Currently it does not execute synchronous drops but only calls user implementations of `AsyncDrop::async_drop` associative function and awaits the returned future. It is not complete as it only recurses into arrays, slices, tuples, and structs and does not have same sensible restrictions as the old `Drop` trait implementation like having the same bounds as the type definition, while code assumes their existence (requires a future work).
This current design uses a workaround as it does not create any custom async destructor state machine types for ADTs, but instead uses types defined in the std library called future combinators (deferred_async_drop, chain, ready_unit).
Also I recommend reading my [explainer](https://zetanumbers.github.io/book/async-drop-design.html).
This is a part of the [MCP: Low level components for async drop](https://github.com/rust-lang/compiler-team/issues/727) work.
Feature completeness:
- [x] `AsyncDrop` trait
- [ ] `async_drop_in_place_raw`/async drop glue generation support for
- [x] Trivially destructible types (integers, bools, floats, string slices, pointers, references, etc.)
- [x] Arrays and slices (array pointer is unsized into slice pointer)
- [x] ADTs (enums, structs, unions)
- [x] tuple-like types (tuples, closures)
- [ ] Dynamic types (`dyn Trait`, see explainer's [proposed design](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#async-drop-glue-for-dyn-trait))
- [ ] coroutines (https://github.com/rust-lang/rust/pull/123948)
- [x] Async drop glue includes sync drop glue code
- [x] Cleanup branch generation for `async_drop_in_place_raw`
- [ ] Union rejects non-trivially async destructible fields
- [ ] `AsyncDrop` implementation requires same bounds as type definition
- [ ] Skip trivially destructible fields (optimization)
- [ ] New [`TyKind::AdtAsyncDestructor`](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#adt-async-destructor-types) and get rid of combinators
- [ ] [Synchronously undroppable types](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#exclusively-async-drop)
- [ ] Automatic async drop at the end of the scope in async context
chore: add some `tracing` to project loading
I wanted to see what's happening during project loading and if it could be parallelized. I'm thinking maybe, but it's not this PR :)
Ignore `-C strip` on MSVC
tl;dr - Define `-Cstrip` to only ever affect the binary; no other build artifacts.
This is necessary to improve cross-platform behavior consistency: if someone wanted debug information to be contained only in separate files on all platforms, they would set `-Cstrip=symbols` and `-Csplit-debuginfo=packed`, but this would result in no PDB files on MSVC.
Resolves#114215
Fix ICE when there is a non-Unicode entry in the incremental crate directory
Fix the ICE that occurs when there is a non-Unicode entry in the incremental crate directory by replacing uses of `to_string_lossy` + `assert_no_characters_lost` with `to_str`. The added test would cause the compiler to ICE before this PR.
fix normalizing in different `ParamEnv`s with the same `InferCtxt`
This PR changes the key of the projection cache from just `AliasTy` to `(AliasTy, ParamEnv)` to allow normalizing in different `ParamEnv`s without resetting caches. Previously, normalizing the same alias in different param envs would always reuse the cached result from the first normalization, which is incorrect if the projection clauses in the param env have changed.
Fixing this bug allows us to get rid of `InferCtxt::clear_caches`, which was only used by the `AutoTraitFinder`, because it requires normalizing in different param envs.
r? `@fmease`
Fix trait solver overflow with `non_local_definitions` lint
This PR fixes the trait solver overflow with the `non_local_definitions` lint reported in https://github.com/rust-lang/rust/issues/123573 using the suggestion from `@lcnr:` https://github.com/rust-lang/rust/issues/123573#issuecomment-2041348320 to use the next trait solver.
~~I have not (yet) tried to create a minimized repro~~ ``@compiler-errors`` did the minimization (thanks you) but I have manually tested on the `starlark-rust` project that it fixes the issue.
Fixes#123573
r? `@lcnr`
Try to generate more meaningful names in json converter
I just found out about rust-analyzer json converter, but I think it would be more convenient, if names were more useful, like using the names of the keys.
Let's look at some realistic arbitrary json:
```json
{
"user": {
"address": {
"street": "Main St",
"house": 3
},
"email": "example@example.com"
}
}
```
I think, new generated code is much easier to read and to edit, than the old:
```rust
// Old
struct Struct1{ house: i64, street: String }
struct Struct2{ address: Struct1, email: String }
struct Struct3{ user: Struct2 }
// New
struct Address1{ house: i64, street: String }
struct User1{ address: Address1, email: String }
struct Root1{ user: User1 }
```
Ideally, if we drop the numbers, I can see it being usable just as is (may be rename root)
```rust
struct Address{ house: i64, street: String }
struct User{ address: Address, email: String }
struct Root{ user: User }
```
Sadly, we can't just drop them, because there can be multiple fields (recursive) with the same name, and we can't just easily retroactively add numbers if the name has 2 instances due to parsing being single pass.
We could ignore the `1` and add number only if it's > 1, but I will leave this open to discussion and right now made it the simpler way
In sum, even with numbers, I think this PR still helps in readability
feat: Allow rust files to be used linkedProjects
With this, script files become more usable as the user can at least add them manually to the linked projects, allowing them to be used "on the (manual) fly" without having to open a separate vscode window that only has files open and no folder.
Also makes build scripts work for them (though no proc-macros, for some reason the dylib field is not populated in the output)
CI: add script for installing NodeJS and update it to v20
I centralized the installation on a single place to make it simple to update the NodeJS version across the board.
Fixes: https://github.com/rust-lang/rust/issues/123965
r? `@Mark-Simulacrum`
Add a lower bound check to `unicode-table-generator` output
This adds a dedicated check for the lower bound
(if it is outside of ASCII range) to the output of the `unicode-table-generator` tool.
This generalized the ASCII-only fast-path, but only for the `Grapheme_Extend` property for now, as that is the only one with a lower bound outside of ASCII.
Make `checked` ops emit *unchecked* LLVM operations where feasible
For things with easily pre-checked overflow conditions -- shifts and unsigned subtraction -- write the checked methods in such a way that we stop emitting wrapping versions of them.
For example, today <https://rust.godbolt.org/z/qM9YK8Txb> neither
```rust
a.checked_sub(b).unwrap()
```
nor
```rust
a.checked_sub(b).unwrap_unchecked()
```
actually optimizes to `sub nuw`. After this PR they do.
cc #103299
