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 6 pull requests #69851

Merged
merged 38 commits into from
Mar 9, 2020
Merged

Rollup of 6 pull requests #69851

merged 38 commits into from
Mar 9, 2020

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Mar 9, 2020

Successful merges:

Failed merges:

r? @ghost

Aaron1011 and others added 30 commits March 4, 2020 16:43
Previously, attributes on 'if' expressions (e.g. #[attr] if true {})
were disallowed during parsing. This made it impossible for macros to
perform any custom handling of such attributes (e.g. stripping them
away), since a compilation error would be emitted before they ever had a
chance to run.

This PR permits attributes on 'if' expressions ('if-attrs' from here on).
Both built-in attributes (e.g. `#[allow]`, `#[cfg]`) are supported.

We still do *not* accept attributes on 'other parts' of an if-else
chain. That is, the following code snippet still fails to parse:

```rust
if true {} #[attr] else if false {} else #[attr] if false {} #[attr]
else {}
```
Co-Authored-By: bjorn3 <bjorn3@users.noreply.github.com>
Additionally whenever possible match C API provided by the LLVM.
Although `stack_overflow::init` runs very early in the process, even
before `main`, there may already be signal handlers installed for things
like the address sanitizer. In that case, just leave it alone, and don't
bother trying to allocate our own signal stacks either.
petrochenkov and others added 8 commits March 9, 2020 12:42
…=Centril

Permit attributes on 'if' expressions

Previously, attributes on 'if' expressions (e.g. `#[attr] if true {}`)
were disallowed during parsing. This made it impossible for macros to
perform any custom handling of such attributes (e.g. stripping them
away), since a compilation error would be emitted before they ever had a
chance to run.

This PR permits attributes on 'if' expressions ('if-attrs' from here on).
Both built-in attributes (e.g. `#[allow]`, `#[cfg]`) and proc-macro attributes are supported.

We still do *not* accept attributes on 'other parts' of an if-else
chain. That is, the following code snippet still fails to parse:

```rust
if true {} #[attr] else if false {} else #[attr] if false {} #[attr]
else {}
```

Closes rust-lang#68618
unix: Don't override existing SIGSEGV/BUS handlers

Although `stack_overflow::init` runs very early in the process, even
before `main`, there may already be signal handlers installed for things
like the address sanitizer. In that case, just leave it alone, and don't
bother trying to allocate our own signal stacks either.

Fixes rust-lang#69524.
Ensure that validity only raises validity errors

For now, only as a debug-assertion (similar to const-prop detecting errors that allocate).

Now includes rust-lang#69646.
[Relative diff](RalfJung/rust@layout-visitor...RalfJung:validity-errors).

r? @oli-obk
librustc_codegen_llvm: Use slices in preference to 0-terminated strings

Additionally whenever possible match C API provided by the LLVM.
rustc_parse: Remove `Parser::normalized(_prev)_token`

Perform the "normalization" (renamed to "uninterpolation") on the fly when necessary.

The final part of rust-lang#69579 rust-lang#69384 rust-lang#69376 rust-lang#69211 rust-lang#69034 rust-lang#69006.
r? @Centril
@Centril
Copy link
Contributor Author

Centril commented Mar 9, 2020

@bors r+ p=1001 rollup=never

@bors
Copy link
Contributor

bors commented Mar 9, 2020

📌 Commit 7e903f8 has been approved by Centril

@bors
Copy link
Contributor

bors commented Mar 9, 2020

🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened

@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 Mar 9, 2020
@Centril Centril added the rollup A PR which is a rollup label Mar 9, 2020
@bors
Copy link
Contributor

bors commented Mar 9, 2020

⌛ Testing commit 7e903f8 with merge 3dbade6...

@bors
Copy link
Contributor

bors commented Mar 9, 2020

☀️ Test successful - checks-azure
Approved by: Centril
Pushing 3dbade6 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 9, 2020
@bors bors merged commit 3dbade6 into rust-lang:master Mar 9, 2020
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #69851!

Tested on commit 3dbade6.
Direct link to PR: #69851

💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Mar 9, 2020
Tested on commit rust-lang/rust@3dbade6.
Direct link to PR: <rust-lang/rust#69851>

💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
@Centril Centril deleted the rollup-iivxvah branch March 9, 2020 15:18
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. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants