Remove markdown injection again
I really tried to make this work, but this stuff is so underdocumented and basically none of the regex options worked for me (not `match`, nor using `begin` and `end` pairs), VSCode basically doesn't help you out at all as it doesn't ever seem to report errors even when debugging an extension, so at this point I'm inclined to just remove this again, as it is only causing issues.
Closes https://github.com/rust-lang/rust-analyzer/issues/15114
Closes https://github.com/rust-lang/rust-analyzer/issues/15111
internal: Add run-tests command
This command is similar to `cargo test` except that it uses r-a to run tests instead of compiling and running them with rustc. This is slower than `cargo test` and it is only useful for me to see a bird view of what needs to be fixed. The current output is:
```
48 passed, 5028 failed, 2 ignored
All tests 174.74s, 648ginstr
```
48 is very low, but higher than what I originally thought.
Now that there is some passing tests, I can show the plan:
https://github.com/rust-lang/rust-analyzer/assets/45197576/76d7d777-1843-4ca4-b7fe-e463bdade6cb
That is, at the end, I want to be able to immediately re run every test after every change. (0.5s is not really immediate, but it's not finished yet, and it is way better than 8s that running a typical test in r-a will take on my system)
Change comparsion for checking if number is negative to include 128
The last byte in Little-Endian representation of negative integers start at 128 (Ox80) till 255 (OxFF). The comparison before the fix didn't check for 128 which made is_negative variable as false.
Potentially fixes#15096
Added a test near positive extermes and two test near negative
extermes as well one for 0.
Added a test using the `as` cast and one with comparison with 0.
feature : assist delegate impl
This PR ( fixes#14386 ) introduces a new IDE assist that generates a trait impl for a struct that delegates a field. This is a draft because the current `ide_db::path_transform::PathTransform` produces some unwanted results when it deals with extern crates, an example of which I attach as a GIF.
GIFs :
1. A general case
![14386-functional](https://github.com/rust-lang/rust-analyzer/assets/20956650/22114959-caa6-45ec-a154-b4b2f458f6b1)
2. A case where `ide_db::path_transform::PathTransform` fails to correctly resolve a property ( take `Allocator` as an example ) to its full path, thus causing an error to occur. ( Not to even mention that resolving this causes another error `use of unstable library feature 'allocator_api'` to occur
![14386-erroneous](https://github.com/rust-lang/rust-analyzer/assets/20956650/922ca715-594e-4168-a579-7c5c006f93aa)
Reason: The last byte in Little Endian representation of negative
integers start at 128 (Ox80) till 255 (OxFF). The comparison before
the fix didn't check for 128 which made is_negative variable as false.
Remove markdown injection for block comments
Closes https://github.com/rust-lang/rust-analyzer/issues/15091
I tried making it work but it doesn't seem possible, as the `*` of the closing `*/` sequence gets eaten by the markdown grammar no matter what.
mmap/munmap/mremamp shims
This adds basic support for `mmap`/`mremap`/`munmap`, with the specific goal of testing allocators targeting Linux under Miri.
This supports `mmap` with `MAP_PRIVATE|MAP_ANONYMOUS`, and `PROT_READ|PROT_WRITE`, and explicitly does not support `MAP_SHARED` (because that's asking for MMIO) as well as any kind of file mapping (because it seems like nobody does `MAP_PRIVATE` on files even though that would be very sensible). And (officially) we don't support `MAP_FIXED`, so we always ignore the `addr` argument.
This supports `mremap` only when the implementation is allowed to move the mapping (so no `MREMAP_FIXED`, no `MREMAP_DONTUNMAP`, and required `MREMAP_MAYMOVE`), and also when the entirety of a region previously mapped by `mmap` is being remapped.
This supports `munmap` but only when the entirety of a region previously mapped by `mmap` is unmapped.
Add `implement_via_object` to `rustc_deny_explicit_impl` to control object candidate assembly
Some built-in traits are special, since they are used to prove facts about the program that are important for later phases of compilation such as codegen and CTFE. For example, the `Unsize` trait is used to assert to the compiler that we are able to unsize a type into another type. It doesn't have any methods because it doesn't actually *instruct* the compiler how to do this unsizing, but this is later used (alongside an exhaustive match of combinations of unsizeable types) during codegen to generate unsize coercion code.
Due to this, these built-in traits are incompatible with the type erasure provided by object types. For example, the existence of `dyn Unsize<T>` does not mean that the compiler is able to unsize `Box<dyn Unsize<T>>` into `Box<T>`, since `Unsize` is a *witness* to the fact that a type can be unsized, and it doesn't actually encode that unsizing operation in its vtable as mentioned above.
The old trait solver gets around this fact by having complex control flow that never considers object bounds for certain built-in traits:
2f896da247/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs (L61-L132)
However, candidate assembly in the new solver is much more lovely, and I'd hate to add this list of opt-out cases into the new solver. Instead of maintaining this complex and hard-coded control flow, instead we can make this a property of the trait via a built-in attribute. We already have such a build attribute that's applied to every single trait that we care about: `rustc_deny_explicit_impl`. This PR adds `implement_via_object` as a meta-item to that attribute that allows us to opt a trait out of object-bound candidate assembly as well.
r? `@lcnr`