Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 7 pull requests #92556

Merged
merged 16 commits into from
Jan 4, 2022
Merged

Rollup of 7 pull requests #92556

merged 16 commits into from
Jan 4, 2022

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Patrick-Poitras and others added 16 commits December 15, 2021 18:35
The code intended to set the IMAGE_SCN_LNK_REMOVE flag for the
.rmeta section, however the value of this flag was set to zero.
Instead use the actual value provided by the object crate.

This dates back to the original introduction of this code in
PR rust-lang#84449, so we were never setting this flag. As I'm not on
Windows, I'm not sure whether that means we were embedding .rmeta
into executables, or whether the section ended up getting stripped
for some other reason.
The documentation on `std::sync::mpsc::Iter` and `std::sync::mpsc::TryIter` provides links to the corresponding `Receiver` methods, unlike `std::sync::mpsc::IntoIter` does.

This was left out in c59b188
Related to rust-lang#29377
  - Do not `#[doc(hidden)]` the `#[derive]` macro attribute

  - Add a link to the reference section to `derive`'s inherent docs

  - Do the same for `#[test]` and `#[global_allocator]`

  - Fix `GlobalAlloc` link (why is it on `core` and not `alloc`?)

  - Try `no_inline`-ing the `std` reexports from `core`

  - Revert "Try `no_inline`-ing the `std` reexports from `core`"

  - Address PR review

  - Also document the unstable macros
…dio-windows, r=Mark-Simulacrum

Modifications to `std::io::Stdin` on Windows so that there is no longer a 4-byte buffer minimum in read().

This is an attempted fix of issue rust-lang#91722, where a too-small buffer was passed to the read function of stdio on Windows. This caused an error to be returned when `read_to_end` or `read_to_string` were called. Both delegate to `std::io::default_read_to_end`, which creates a buffer that is of length >0, and forwards it to `std::io::Stdin::read()`. The latter method returns an error if the length of the buffer is less than 4, as there might not be enough space to allocate a UTF-16 character. This creates a problem when the buffer length is in `0 < N < 4`, causing the bug.

The current modification creates an internal buffer, much like the one used for the write functions

I'd also like to acknowledge the help of ``@agausmann`` and ``@hkratz`` in detecting and isolating the bug, and for suggestions that made the fix possible.

Couple disclaimers:

- Firstly, I didn't know where to put code to replicate the bug found in the issue. It would probably be wise to add that case to the testing suite, but I'm afraid that I don't know _where_ that test should be added.
- Secondly, the code is fairly fundamental to IO operations, so my fears are that this may cause some undesired side effects ~or performance loss in benchmarks.~ The testing suite runs on my computer, and it does fix the issue noted in rust-lang#91722.
- Thirdly, I left the "surrogate" field in the Stdin struct, but from a cursory glance, it seems to be serving the same purpose for other functions. Perhaps merging the two would be appropriate.

Finally, this is my first pull request to the rust language, and as such some things may be weird/unidiomatic/plain out bad. If there are any obvious improvements I could do to the code, or any other suggestions, I would appreciate them.

Edit: Closes rust-lang#91722
Constify `Box<T, A>` methods

Tracking issue: none yet

Most of the methods bounded on `~const`. `intrinsics::const_eval_select` is used for handling an allocation error.

<details><summary>Constified API</summary>

```rust
impl<T, A: Allocator> Box<T, A> {
    pub const fn new_in(x: T, alloc: A) -> Self
    where
        A: ~const Allocator + ~const Drop;
    pub const fn try_new_in(x: T, alloc: A) -> Result<Self, AllocError>
    where
        T: ~const Drop,
        A: ~const Allocator + ~const Drop;
    pub const fn new_uninit_in(alloc: A) -> Box<mem::MaybeUninit<T>, A>
    where
        A: ~const Allocator + ~const Drop;
    pub const fn try_new_uninit_in(alloc: A) -> Result<Box<mem::MaybeUninit<T>, A>, AllocError>
    where
        A: ~const Allocator + ~const Drop;
    pub const fn new_zeroed_in(alloc: A) -> Box<mem::MaybeUninit<T>, A>
    where
        A: ~const Allocator + ~const Drop;
    pub const fn try_new_zeroed_in(alloc: A) -> Result<Box<mem::MaybeUninit<T>, A>, AllocError>
    where
        A: ~const Allocator + ~const Drop;
    pub const fn pin_in(x: T, alloc: A) -> Pin<Self>
    where
        A: 'static,
        A: 'static + ~const Allocator + ~const Drop,
    pub const fn into_boxed_slice(boxed: Self) -> Box<[T], A>;
    pub const fn into_inner(boxed: Self) -> T
    where
        Self: ~const Drop,
}

impl<T, A: Allocator> Box<MaybeUninit<T>, A> {
    pub const unsafe fn assume_init(self) -> Box<T, A>;
    pub const fn write(mut boxed: Self, value: T) -> Box<T, A>;
    pub const unsafe fn from_raw_in(raw: *mut T, alloc: A) -> Self;
    pub const fn into_raw_with_allocator(b: Self) -> (*mut T, A);
    pub const fn into_unique(b: Self) -> (Unique<T>, A);
    pub const fn allocator(b: &Self) -> &A;
    pub const fn leak<'a>(b: Self) -> &'a mut T
    where
        A: 'a;
    pub const fn into_pin(boxed: Self) -> Pin<Self>
    where
        A: 'static;
}

unsafe impl<#[may_dangle] T: ?Sized, A: Allocator> const Drop for Box<T, A>;
impl<T: ?Sized, A: Allocator> const From<Box<T, A>> for Pin<Box<T, A>>
where
    A: 'static;
impl<T: ?Sized, A: Allocator> const Deref for Box<T, A>;
impl<T: ?Sized, A: Allocator> const DerefMut for Box<T, A>;
impl<T: ?Sized, A: Allocator> const Unpin for Box<T, A> where A: 'static;
```

</details>

<details><summary>Example</summary>

```rust
pub struct ConstAllocator;

unsafe impl const Allocator for ConstAllocator {
    fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError> {
        unsafe {
            let ptr = core::intrinsics::const_allocate(layout.size(), layout.align());
            Ok(NonNull::new_unchecked(ptr as *mut [u8; 0] as *mut [u8]))
        }
    }

    unsafe fn deallocate(&self, _ptr: NonNull<u8>, _layout: Layout) {
        /* do nothing */
    }

    fn allocate_zeroed(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError> {
        self.allocate(layout)
    }

    unsafe fn grow(
        &self,
        _ptr: NonNull<u8>,
        _old_layout: Layout,
        _new_layout: Layout,
    ) -> Result<NonNull<[u8]>, AllocError> {
        unimplemented!()
    }

    unsafe fn grow_zeroed(
        &self,
        _ptr: NonNull<u8>,
        _old_layout: Layout,
        _new_layout: Layout,
    ) -> Result<NonNull<[u8]>, AllocError> {
        unimplemented!()
    }

    unsafe fn shrink(
        &self,
        _ptr: NonNull<u8>,
        _old_layout: Layout,
        _new_layout: Layout,
    ) -> Result<NonNull<[u8]>, AllocError> {
        unimplemented!()
    }

    fn by_ref(&self) -> &Self
    where
        Self: Sized,
    {
        self
    }
}

#[test]
fn const_box() {
    const VALUE: u32 = {
        let mut boxed = Box::new_in(1u32, ConstAllocator);
        assert!(*boxed == 1);

        *boxed = 42;
        assert!(*boxed == 42);

        *boxed
    };

    assert!(VALUE == 42);
}
```

</details>
Actually set IMAGE_SCN_LNK_REMOVE for .rmeta

The code intended to set the IMAGE_SCN_LNK_REMOVE flag for the
.rmeta section, however the value of this flag was set to zero.
Instead use the actual value provided by the object crate.

This dates back to the original introduction of this code in
PR rust-lang#84449, so we were never setting this flag. As I'm not on
Windows, I'm not sure whether that means we were embedding .rmeta
into executables, or whether the section ended up getting stripped
for some other reason.
…ochenkov

Make the documentation of builtin macro attributes accessible

`use ::std::prelude::v1::derive;` compiles on stable, so, AFAIK, there is no reason to have it be `#[doc(hidden)]`.

  - What it currently looks like for things such as `#[test]`, `#[derive]`, `#[global_allocator]`: https://doc.rust-lang.org/1.57.0/core/prelude/v1/index.html#:~:text=Experimental-,pub,-use%20crate%3A%3Amacros%3A%3Abuiltin%3A%3Aglobal_allocator

    <img width="767" alt="Screen Shot 2021-12-31 at 17 49 46" src="https://user-images.githubusercontent.com/9920355/147832999-cbd747a6-4607-4df6-8e57-c1675dcbc1c3.png">

    and in `::std` they're just straight `hidden`.

    <img width="452" alt="Screen Shot 2021-12-31 at 17 53 18" src="https://user-images.githubusercontent.com/9920355/147833105-c5ff8cd1-9e4d-4d2b-9621-b36aa3cfcb28.png">

  - Here is how it looks like with this PR (assuming the `Rustc{De,En}codable` ones are not reverted):

    <img width="778" alt="Screen Shot 2021-12-31 at 17 50 55" src="https://user-images.githubusercontent.com/9920355/147833034-84286342-dbf7-4e6e-9062-f39cd6c286a4.png">

    <img width="291" alt="Screen Shot 2021-12-31 at 17 52 54" src="https://user-images.githubusercontent.com/9920355/147833109-c92ed55c-51c6-40a2-9205-f834d1e349c0.png">

 Since this involves doc people to chime in, and since `jyn` is on vacation, I'll cc `@GuillaumeGomez` and tag the `rustdoc` team as well
…petrochenkov

Suggest single quotes when char expected, str provided

If a type mismatch occurs where a char is expected and a string literal is provided, suggest changing the double quotes to single quotes.

We already provide this suggestion in the other direction ( ' -> " ).

Especially useful for new rust devs used to a language in which single/double quotes are interchangeable.

Fixes rust-lang#92479.
intra-doc: Make `Receiver::into_iter` into a clickable link

The documentation on `std::sync::mpsc::Iter` and `std::sync::mpsc::TryIter` provides links to the corresponding `Receiver` methods, unlike `std::sync::mpsc::IntoIter` does.

This was left out in c59b188
Related to rust-lang#29377
…acrum

revert rust-lang#92254 "Bump gsgdt to 0.1.3"

This reverts rust-lang#92254 since gsgdt 0.1.3 was yanked: rust-lang#92254 (comment)
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jan 4, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Jan 4, 2022

📌 Commit 76c0271 has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 4, 2022
@bors
Copy link
Contributor

bors commented Jan 4, 2022

⌛ Testing commit 76c0271 with merge 7d6f948...

@bors
Copy link
Contributor

bors commented Jan 4, 2022

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 7d6f948 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 4, 2022
@bors bors merged commit 7d6f948 into rust-lang:master Jan 4, 2022
@rustbot rustbot added this to the 1.59.0 milestone Jan 4, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (7d6f948): comparison url.

Summary: This change led to large relevant mixed results 🤷 in compiler performance.

  • Moderate improvement in instruction counts (up to -1.6% on incr-full builds of issue-88862)
  • Large regression in instruction counts (up to 6.6% on full builds of tokio-webpush-simple)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

@rustbot rustbot added the perf-regression Performance regression. label Jan 5, 2022
@rylev
Copy link
Member

rylev commented Jan 12, 2022

@matthiaskrgr this leads to regression in only one test case, and as you can see the regressions seemed to be localized to LLVM passes. I'm not 100% sure what the cause of this could be or why it's so localized to one test case.

Given the limited nature of the regression, I'll mark this as triaged

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Jan 12, 2022
@matthiaskrgr matthiaskrgr deleted the rollup-s9vopuj branch February 13, 2022 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.