Cleanup markdown span handling, take 2
This PR includes the cleanups made in #80244 except for the removal of `locate()`.
While the biggest conceptual part in #80244 was the removal of `locate()`, it introduced a diagnostic regression.
Additional cleanup:
- Use `RefCell` to avoid building two separate vectors for the links
Work to do:
- [ ] Decide if `locate()` can be simplified by assuming `s` is always in `md`
- [ ] Should probably add some tests that still provide the undesired diagnostics causing #80381
cc `@jyn514` This is the best I can do without patching Pulldown to provide multiple ranges for reference-style links. Also, since `locate` is probably more efficient than `rfind` (at least it's constant time), I decided to not check the link type and just cover every &str as it was before.
Initial support for Rust 2021.
Clippy treated Rust 2021 as Rust 2015, because 2018 was checked with `==` instead of `>=`. This fixes that, such that 2018-specific things are also enabled for 2021.
changelog: Added support for Rust 2021.
`const_generics_defaults`: don't ICE in the unimplemented parts
The thought was that we could use `todo!`s to ensure we wouldn't forget to implement parts of the experimental gate.
However, that can also lead to a suboptimal experience for users as shown in #80589 having both the error/warning about the experimental feature, and the ICE.
Fixes#80589
r? `@varkor`
improve unconditional_panic description
The fact that the lint is triggered by the ConstProp pass is an implementation detail, I do not think that this should be mentioned in the description.
Cc `@oli-obk` `@ehuss`
rustc_serialize: specialize opaque encoding and decoding of some u8 sequences
This specializes encoding and decoding of some contiguous u8 sequences to use a more efficient implementation. The default implementations process each u8 individually, but that isn't necessary for the opaque encoder and decoder. The opaque encoding for u8s is a no-op, so we can just copy entire sequences as-is, rather than process them byte by byte.
This also changes some encode and decode implementations for contiguous sequences to forward to the slice and vector implementations, so that they can take advantage of the new specialization when applicable.
Enable ASan, TSan, UBSan for aarch64-apple-darwin.
I confirmed ASan, TSan, UBSan all work for me locally with `clang` on my new Macbook Air.
~This requires https://github.com/rust-lang/llvm-project/pull/86~
Add docs note about `Any::type_id` on smart pointers
Fixes#79868.
There's an issue I've run into a couple times while using values of type `Box<dyn Any>` - essentially, calling `value.type_id()` doesn't dereference to the trait object, but uses the implementation of `Any` for `Box<dyn Any>`, giving us the `TypeId` of the container instead of the object inside it.
I couldn't find any notes about this in the documentation and - while it could be inferred from existing knowledge of Rust and the blanket implemenation of `Any` - I think it'd be nice to have a note about it in the documentation for the `any` module.
Anyways, here's a first draft of a section about it. I'm happy to revise wording :)
Remove many unnecessary manual link resolves from library
Now that #76934 has merged, we can remove a lot of these! E.g, this is
no longer necessary:
[`Vec<T>`]: Vec
cc `@jyn514`
Use Array.prototype.filter instead of open-coding
Part of #79052, originally suggested in https://github.com/rust-lang/rust/pull/79052#discussion_r523468743 by `@jyn514`
Besides making main.js smaller (always a plus), this also performs better by using the optimized filter implementation in your browser's JavaScript engine (according to `@GuillaumeGomez,` an 84% performance improvement).
Fix tests that incorrectly used `!@has` instead of `@!has`
The command is ``@!has`,` not `!`@has`.` I don't think these checks were
doing anything before! Ideally we would accept `!`@has`` as well, or at
least fail tests that use `!`@has`.` The current behavior seems to be
silently ignoring the check, which is very confusing.
r? `@GuillaumeGomez`
Clippy treated Rust 2021 as Rust 2015, because 2018 was checked with
`==` instead of `>=`. This fixes that, such that 2018-specific things
are also enabled for 2021.
In which we start to parse const generics defaults
As discussed in this [zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/const.20generic.20defaults), this PR extracts the parsing parts from `@JulianKnodt's` PR #75384 for a better user-experience using the newly stabilized `min_const_generics` (albeit temporary) as shown in #80507: trying to use default values on const generics currently results in parse errors, as if the user didn't use the correct syntax (which is somewhat true but also misleading).
This PR extracts (and slightly modifies in a couple places) `@JulianKnodt's` parsing code (with attribution if I've done everything correctly), AST and HIR changes, and feature gate setup.
This feature is now marked as "incomplete" and thus will also print out the expected "const generics default values are unstable" error instead of a syntax error. Note that, as I've only extracted the parsing part, the actual feature will not work at all if enabled. There will be ICEs, and inference errors on the const generics default values themselves.
Fixes#80507.
Once this merges, I'll:
- modify the const generics tracking issue to refer to the `const_generics_defaults` gate rather than the older temporary name it uses there.
- create the GH `F-const_generics_defaults` label
r? `@varkor`
