| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
This will be re-enabled sooner or later depending on results of further
investigation.
Fixes #54462
|
|
This commit fixes a buffer overflow issue in the standard library
discovered by Scott McMurray where if a large number was passed to
`str::repeat` it may cause and out of bounds write to the buffer of a `Vec`.
This bug was accidentally introduced in #48657 when optimizing the
`str::repeat` function. The bug affects stable Rust releases 1.26.0 to
1.29.0. We plan on backporting this fix to create a 1.29.1 release, and
the 1.30.0 release onwards will include this fix.
The fix in this commit is to introduce a deterministic panic in the case of
capacity overflow. When repeating a slice where the resulting length is larger
than the address space, there’s no way it can succeed anyway!
The standard library and surrounding libraries were briefly checked to see if
there were othere instances of preallocating a vector with a calculation that
may overflow. No instances of this bug (out of bounds write due to a calculation
overflow) were found at this time.
Note that this commit is the first steps towards fixing this issue,
we'll be making a formal post to the Rust security list once these
commits have been merged.
|
|
|
|
|
|
|
|
Beta still requires them.
|
|
|
|
|
|
Added in #52149 the discussion in #53514 is showing how we may not want to
actually add this attribute to the atomic types. While we continue to
debate #53514 this commit reverts the addition of the `transparent` attribute
before it hits stable.
|
|
[beta] Properly prevent the promotion of unstable const fns
backport of https://github.com/rust-lang/rust/pull/53699
r? @nikomatsakis (the other PR was merged and beta nominated but not beta approved)
|
|
[beta] update backtrace-sys to 0.1.24
This is the other part of #53377 that was missed in the #53880 backport.
r? @pietroalbini
|
|
The former code used `target.contains("64")` to detect Elf64 targets,
but this is inaccurate in a few cases:
- `s390x-unknown-linux-gnu` is 64-bit
- `sparcv9-sun-solaris` is 64-bit
- `x86_64-unknown-linux-gnux32` is 32-bit
Instead the `std` build script can use `CARGO_CFG_TARGET_POINTER_WIDTH`
to reliably detect 64-bit targets for libbacktrace.
Also update to backtrace-sys 0.1.24 for alexcrichton/backtrace-rs#122.
|
|
|
|
|
|
If we detect a local rebuild (e.g. bootstrap compiler is the same version as target compiler), we set stage to 1.
When trying to build e.g. UnstableBook, we use Mode::ToolBootstrap and stage is 1.
Just allow Mode::ToolBootstrap and stagge != 0 if we are in a local_rebuild
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
The former code used `target.contains("64")` to detect Elf64 targets,
but this is inaccurate in a few cases:
- `s390x-unknown-linux-gnu` is 64-bit
- `sparcv9-sun-solaris` is 64-bit
- `x86_64-unknown-linux-gnux32` is 32-bit
Instead the `std` build script can use `CARGO_CFG_TARGET_POINTER_WIDTH`
to reliably detect 64-bit targets for libbacktrace.
Also update to backtrace-sys 0.1.24 for alexcrichton/backtrace-rs#122.
|
|
|
|
`Mark`"
This reverts commit b15785b67133b5017f141d1fda1dd3dcf331b4b4.
|
|
|
|
|
|
|
|
[beta] Don't sanity check function pointers in vtables
cc https://github.com/rust-lang/rust/issues/53401
There's no beta nomination because the full fix (https://github.com/rust-lang/rust/pull/53424) is not backportable
|
|
fallback
|
|
|
|
This hack was removed in #50949, but without it I found that building
`std` with full debuginfo would print many LLVM `DW_OP_LLVM_fragment`
errors, then die `LLVM ERROR: Failed to strip malformed debug info`.
It doesn't seem to be a problem for LLVM 6, so we can re-enable the hack
just for older LLVM.
This reverts commit da579ef75e4a8ca11fb98b24a0a3ea0c7ccffeeb.
Fixes #53204.
r? @eddyb
|
|
This allows import resolution to progress in cases like #53140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
necessary.
Namely, the code here was trying to be clever, and say "lets not
report diagnostics when we 'know' NLL will report an error about them
in the future."
The problem is that in migration mode, when no error was reported here,
the NLL error that we "knew" was coming was downgraded to a warning (!).
This fixes that by only doing the "clever" skipping of region error reporting
when we are not in migration mode.
Rather than make a separate test for issue 53026, I just took the test
that uncovered this in a first place, and extended it (via our
revisions system) to explicitly show all three modes in action:
ACT-borrowck, NLL, and NLL migration mode.
(Tto be honest I hope not to have to add such revisions to many tests.
Instead I hope to adopt some sort of new `compare-mode` for either
borrowck=migrate or for the 2018 edition as a whole.)
|
|
|
|
|
|
|
|
Includes backporting the rustc workspace hack
|
|
|
|
|
|
Revert "Stabilize to_bytes and from_bytes for integers."
This reverts commit c8f9b84b393915a48253e3edc862c15a9b7152a7 / PR https://github.com/rust-lang/rust/pull/51835, and reopens the tracking issue https://github.com/rust-lang/rust/issues/49792.
These methods were stabilized in Rust 1.29, which is still in Nightly as of this writing. So my understanding is that it is still time to change our minds. Given the ongoing discussion in https://github.com/rust-lang/rust/pull/51919 about possibly renaming these APIs and since 1.29 goes to beta soon, I’d like to revert this stabilization for now until a decision is made in that PR. It’s possible that a decision will be made in time for 1.29, but there is no urgency. At most I expect this functionality to make it into 1.30.
|
|
Delete unused code in rustdoc
Also hid the unused crate exports of rustdoc. This is technically a breaking change but we don't even ship librustdoc in the sysroot so I don't expect breakage.
|
|
update books for new release
r? @Mark-Simulacrum
|
|
|
|
Fixes #51649
|
|
Normalization results are memoized, so this may not be worth it, but it
seems easy enough to do.
|
|
|
|
|