see also https://github.com/rust-lang/rust/pull/23104/files

to support newer versions of libressl in rust builds

Co-authored-by: dylanaraps <dylan.araps@gmail.com>

Prevent accidental too-long borrows by ensuring only encapsulated
locking.

Consider this example: small_set = 0..2, large_set = 0..1000.

To efficiently compute the union of these sets, we should
* take all elements of the larger set
* for each element of the smaller set check it is not in the larger set

This is exactly what this commit does.

This particular optimization was implemented a year ago, but the
author mistaken `<` and `>`.

Someone forgot to update the error message after `#[proc_macro]` and
`#[proc_macro_attribute]` were stabilized.

- Use `Option<NonZeroU32>` to represent issue numbers.

…peck-error-codes, r=Mark-Simulacrum

Clean up librustc_typeck error_codes file

r? @Dylan-DPC

…, r=alexcrichton

remove vestigial comments referring to defunct numeric trait hierarchy

I've been poking around the numeric trait hierarchy and also some of the actual numeric type implementations.

This is a small change but a matter of effective communication.  I looked for other related references and saw none.

bump openssl version

Fixes rust-lang#65808

This PR updates `openssl` and `openssl-sys` to support newer versions of `libressl` in `rust` builds.

… r=alexcrichton

Drop long-section-names linker workaround for windows-gnu

If we can trust objdump Rust doesn't emit sections loaded at runtime longer than 8 characters on windows-gnu (but still does on linux-gnu), debug sections are not affected by that limit.
I've ran tests and built few crates using exactly the same mingw-w64 version as Rusts CI just fine using **x86_64** toolchain.

The motivation for this change is making LLD work (it doesn't support `--enable-long-section-names`) with this target without hacks.

Bit of history:
The behaviour of LD changed in Binutils 2.20 released on 2009-10-16 and `--enable-long-section-names` was added to return to the old non conformant behaviour. Looking at the comment I can only guess there was a bug fixed in newer versions.

This workaround was added in rust-lang#13315 half a decade ago.

…crichton

make the error message more readable

When I type it wrong e.g. `--stage --bless`, missing a number here, this change would make it more explicit what's going wrong here.

…innison

Add rustdoc doc

r? @kinnison

…nikomatsakis

Move lock into CodeStats

Prevent (theoretical) accidental too-long borrows by ensuring only encapsulated locking.

…r, r=Centril

Fix error message about exported symbols from proc-macro crates

Someone forgot to update the error message after `#[proc_macro]` and
`#[proc_macro_attribute]` were stabilized.

Fix HashSet::union performance

Consider this example: small_set = 0..2, large_set = 0..1000.

To efficiently compute the union of these sets, we should
* take all elements of the larger set
* for each element of the smaller set check it is not in the larger set

This is exactly what this commit does.

This particular optimization was implemented a year ago, but the
author mistaken `<` and `>`.

…-0, r=varkor

support issue = "none" in unstable attributes

This works towards fixing rust-lang#41260.

This PR allows the use of `issue = "none"` in unstable attributes and makes changes to internally store the issue number as an `Option<NonZeroU32>`. For example:

```rust
#[unstable(feature = "unstable_test_feature", issue = "none")]
fn unstable_issue_none() {}
```

It was not made optional because feedback seen here rust-lang#60860 suggested that people might forget the issue field if it was optional.

I could not remove the current uses of `issue = "0"` (of which there are a lot) because the stage 0 compiler expects the old syntax. Once this is available in the stage 0 compiler we can replace all uses of `"0"` with `"none"` and no longer allow `"0"`. This is my first time contributing, so I'm not sure what the protocol is with two-part things like this, so some guidance would be appreciated.

r? @varkor

…acrum

Tiny cleanup to size assertions

The need to write `#[cfg(target_arch = "x86_64")]` twice mildly annoys me, the full paths look better in comparison.