codegen_llvm: verify that inline assembly operands are scalars
Another set of inline assembly fixes. This time let's emit an error message when the operand value cannot be coerced into the operand constraint.
Two questions:
1) Should I reuse `E0668` which was introduced in #54568 or just use `E0669` as it stands because they do mean different things, but maybe that's not too user-friendly. Just a thought.
2) The `try_fold` returns the operand which failed to be converted into a scalar value, any suggestions on how to use that in the error message?
Thanks!
Currently lldb tests are run only on macOS, and gdb tests are only run
elsewhere. This patch changes this to run tests depending on what is
available.
One test is changed, as it was previously marked as failing on macOS,
whereas really it is a generic failure with lldb.
Closes#54721
miri engine: basic support for pointer provenance tracking
This enriches pointers with a new member, `tag`, that can be used to do provenance tracking. This is a new type parameter that propagates up through everything. It defaults to `()` (no tag), which is also the value used by CTFE -- but miri will use another type.
The only actually interesting piece here, I think, is what I had to do in the memory's `get`. The problem is that `tcx` (storing the allocations for statics) uses `()` for provenance information. But the machine might need another tag. The machine has a function to do the conversion, but if a conversion actually happened, we need to store the result of this *somewhere* -- we cannot return a pointer into `tcx` as we usually would.
So I introduced `MonoHashMap` which uses `RefCell` to be able to insert new entries even when we just have a shared ref. However, it is important that we can also return shared refs into the map without holding the `RefCell` opan. This is achieved by boxing the values stored in the map, so their addresses remain stable even when the map's table gets reallocated. This is all implemented in `mono_hash_map.rs`.
NOTE: This PR also contains the commits from https://github.com/rust-lang/rust/pull/54380#issuecomment-423130753. Only the [last two commits](8e74ee0998..HEAD) are new.
NLL is missing struct field suggestion
Part of #52663.
This commit adds suggestions to change the definitions of fields in
struct definitions from immutable references to mutable references.
r? @nikomatsakis
cc @pnkfelix
We originally didn't have threads, and now we're starting to add them!
Make sure we properly synchronize access to dlmalloc when the `atomics`
feature is enabled for `wasm32-unknown-unknown`.
This uses a copied version of `check_unused_parens_expr` that is
specific to `ast::Pat`. `check_unused_parens_` could possibly be made
more generic to work with any `ast::*` that has `node` and `span`
fields.
This also only checks for the case of parens around the wildcard
pattern. It covers the case highlighted in the issue, but could check
for a lot more.
Run debuginfo tests against rust-enabled lldb, when possible
If the rust-enabled lldb was built, then use it when running the
debuginfo tests. Updating the lldb submodule was necessary as this
needed a way to differentiate the rust-enabled lldb, so I added a line
to the --version output.
This adds compiletest commands to differentiate between the
rust-enabled and non-rust-enabled lldb, as is already done for gdb. A
new "rust-lldb" header directive is also added, but not used in this
patch; I plan to use it in #54004.
This updates all the tests.
- Detect one element array of `Range` type, which is potentially a typo:
`for _ in [0..10] {}` where iterating between `0` and `10` was intended.
(#23141)
- Suggest `.bytes()` and `.chars()` for `String`.
- Suggest borrowing or `.iter()` on arrays (#36391)
- Suggest using range literal when iterating on integers (#34353)
- Do not suggest `.iter()` by default (#50773, #46806)
Fix range literals borrowing suggestions
Fixes#54505. The compiler issued incorrect range borrowing suggestions (missing `()` around borrows of range literals). This was not correct syntax (see the issue for an example).
With changes in this PR, this is fixed for all types of `Range` literals.
Thanks again to @varkor and @estebank for their invaluable help and guidance.
r? @varkor
