Rollup of 12 pull requests #109490
Closed
Rollup of 12 pull requests #109490
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lines_any method was replaced with lines method, so it makes sense to rename this structure to match new name. Co-authored-by: Ian Jackson <[email protected]>
Previously "bare\r" was split into ["bare"] even though the documentation said that only LF and CRLF count as newlines. This fix is a behavioural change, even though it brings the behaviour into line with the documentation, and into line with that of `std::io::BufRead::lines()`. This is an alternative to rust-lang#91051, which proposes to document rather than fix the behaviour. Fixes rust-lang#94435. Co-authored-by: Ian Jackson <[email protected]>
Fundamentally, querying the OS for error codes is a process that is deeply subject to the whims of chance and fortune. We can account for OS, but not for every combination of platform APIs. A compiled binary may not recognize new errors introduced years later. We should clarify a few especially odd situations, and what they mean: We can effectively promise nothing. This allows removing mention of ErrorKind::Uncategorized. That error variant is hidden quite deliberately, so we should not explicitly mention it.
Co-authored-by: Michael Howell <[email protected]>
- check compiler stage before forcing for stage2. - check if download_rustc is not set before forcing for stage1. Signed-off-by: ozkanonur <[email protected]>
Keep ids of the documented items themselves, not their parent modules. Parent modules can be retreived from those ids when necessary.
This option was added to LLVM in https://reviews.llvm.org/D121750?id=416339. It makes `llvm_unreachable` in builds without assertions compile to an `LLVM_BUILTIN_TRAP` instead of `LLVM_BUILTIN_UNREACHABLE` (which causes undefined behavior and is equivalent to `std::hint::unreachable_unchecked`). Having compiler bugs triggering undefined behavior generally seems undesirable and inconsistent with Rust's goals. There is a check in `src/tools/tidy/src/style.rs` to reject code using `llvm_unreachable`. But it is used a lot within LLVM itself. For instance, this changes a failure I get compiling `libcore` for m68k from a `SIGSEGV` to `SIGILL`, which seems better though it still doesn't provide a useful message without switching to an LLVM build with asserts. It may be best not to do this if it noticeably degrades compiler performance, but worthwhile if it doesn't do so in any significant way. I haven't looked into what benchmarks there are for Rustc. That should be considered before merging.
Marked ignore due to difficulty getting doctests to pass cross-platform
…, r=ChrisDenton Fix handling of trailing bare CR in str::lines Continuing from rust-lang#91191. Fixes rust-lang#94435.
…idden-documentation, r=ChrisDenton Clarify `Error::last_os_error` can be weird Fundamentally, querying the OS for error codes is a process that is deeply subject to the whims of chance and fortune. We can account for OS, but not for every combination of platform APIs. A compiled binary may not recognize new errors introduced years later. We should clarify a few especially odd situations, and what they mean: We can effectively promise nothing... if you ask for Rust to decode errors where none have occurred. This allows removing mention of ErrorKind::Uncategorized. That error variant is hidden deliberately, so we should not explicitly mention it. This fixes rust-lang#106937. Since you had an opinion also: Does this solution seem acceptable? r? `@ChrisDenton`
Change text -> rust highlighting in sanitizer.md Not sure why this has syntax highlighting turned off, but it doesn't need to be Relevant page: https://doc.rust-lang.org/beta/unstable-book/compiler-flags/sanitizer.html
…ce, r=eholk move Option::as_slice to intrinsic ```@scottmcm``` suggested on rust-lang#109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation. cc ```@nikic``` as this should hopefully unblock rust-lang#107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
…meGomez Render source page layout with Askama ~~I was looking at making `code_html` render into the buffer instead of in advance, but it turned out to need a pretty big refactor, so starting with rearranging the high-level layout.~~ Found another approach which required much less changes cc rust-lang#108868
…-Simulacrum Remove `VecMap` Not sure what the use of this data structure is over just using `FxIndexMap` or a `Vec`. r? ``@ghost``
refactor `fn bootstrap::builder::Builder::compiler_for` logic - check compiler stage before forcing for stage2. - check if download_rustc is not set before forcing for stage1. resolves rust-lang#109286
…omez rustdoc: Cleanup parent module tracking for doc links Keep ids of the documented items themselves, not their parent modules. Parent modules can be retreived from those ids when necessary. Fixes rust-lang#108501. That issue could be fixed in a more local way, but this refactoring is something that I wanted to do since rust-lang#93805 anyway.
…strieb Update links for custom discriminants. The discriminant documentation was updated in rust-lang/reference#1055 which changed the layout a bit. This updates the links to the updated locations.
… r=ozkanonur Set LLVM `LLVM_UNREACHABLE_OPTIMIZE` to `OFF` This option was added to LLVM in https://reviews.llvm.org/D121750?id=416339. It makes `llvm_unreachable` in builds without assertions compile to an `LLVM_BUILTIN_TRAP` instead of `LLVM_BUILTIN_UNREACHABLE` (which causes undefined behavior and is equivalent to `std::hint::unreachable_unchecked`). Having compiler bugs triggering undefined behavior generally seems undesirable and inconsistent with Rust's goals. There is a check in `src/tools/tidy/src/style.rs` to reject code using `llvm_unreachable`. But it is used a lot within LLVM itself. For instance, this changes a failure I get compiling `libcore` for m68k from a `SIGSEGV` to `SIGILL`, which seems better though it still doesn't provide a useful message without switching to an LLVM build with asserts. It may be best not to do this if it noticeably degrades compiler performance, but worthwhile if it doesn't do so in any significant way. I haven't looked into what benchmarks there are for Rustc. That should be considered before merging.
Remove Ty::is_region_ptr Fixes rust-lang#109372
Custom MIR: Allow optional RET type annotation
This currently doesn't compile because the type of `RET` is inferred, which fails if RET is a composite type and fields are initialised separately.
```rust
#![feature(custom_mir, core_intrinsics)]
extern crate core;
use core::intrinsics::mir::*;
#[custom_mir(dialect = "runtime", phase = "optimized")]
fn fn0() -> (i32, bool) {
mir! ({
RET.0 = 0;
RET.1 = true;
Return()
})
}
```
```
error[E0282]: type annotations needed
--> src/lib.rs:8:9
|
8 | RET.0 = 0;
| ^^^ cannot infer type
For more information about this error, try `rustc --explain E0282`.
```
This PR allows the user to manually specify the return type with `type RET = ...;` if required:
```rust
#[custom_mir(dialect = "runtime", phase = "optimized")]
fn fn0() -> (i32, bool) {
mir! (
type RET = (i32, bool);
{
RET.0 = 0;
RET.1 = true;
Return()
}
)
}
```
The syntax is not optimal, I'm happy to see other suggestions. Ideally I wanted it to be a normal type annotation like `let RET: ...;`, but this runs into the multiple parsing options error during macro expansion, as it can be parsed as a normal `let` declaration as well.
r? ``@oli-obk`` or ``@tmiasko`` or ``@JakobDegen``
rustbot
added
the
S-waiting-on-review
rustbot
added
T-bootstrap
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
@bors r+ rollup=never p=5 |
|
💡 This pull request was already approved, no need to approve it again.
|
|
⌛ Testing commit 4aba0a0 with merge 5c02b83c5534986a0b5f52c5c86a67ad86863f45... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
☔ The latest upstream changes (presumably #108442) made this pull request unmergeable. Please resolve the merge conflicts. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Error::last_os_errorcan be weird #106964 (ClarifyError::last_os_errorcan be weird)VecMap#109280 (RemoveVecMap)fn bootstrap::builder::Builder::compiler_forlogic #109295 (refactorfn bootstrap::builder::Builder::compiler_forlogic)LLVM_UNREACHABLE_OPTIMIZEtoOFF#109373 (Set LLVMLLVM_UNREACHABLE_OPTIMIZEtoOFF)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup