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 #93768

Closed
wants to merge 16 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

estebank and others added 16 commits December 15, 2021 01:40
This shouldn't have any change in practice, but it seems good to enforce.
…ator, r=matthewjasper

Point at type when a `static` `#[global_allocator]` doesn't `impl` `GlobalAlloc`
…=Mark-Simulacrum

Avoid accidentally enabling unstable features in compilers

This allows rustbuild to control whether crates can use nightly features or not.
In practice, it has no effect because `builder.rs` already sets RUSTC_BOOTSTRAP unconditionally.
Do not suggest char literal for zero-length strings

PR rust-lang#92507 adds a hint to switch to single quotes when a char is expected and a single-character string literal is provided.

The check to ensure the string literal is one character long missed the 0-char case, and would incorrectly offer the hint.

This PR adds the missing check, and a test case to confirm the new behavior.
Don't constrain projection predicates with inference vars in GAT substs

cc rust-lang#91762

Not a fix, but a mitigation to prevent a backwards-compatible hazard where we normalize using a predicate only because it's the only one available, but shouldn't. This would constrain an inference variable which didn't really want. We already do this when selecting a projection candidate, which isn't always correct. But changing that is a problem for a different day.

Also found out that a suggestion for `await`ing a future was using the wrong substs.

r? `@nikomatsakis`
Use `NtCreateFile` instead of `NtOpenFile` to open a file

Generally the internal `Nt*` functions should be avoided but when we do need to use one we should stick to the most commonly used for the job. To that end, this PR replaces `NtOpenFile` with `NtCreateFile`.

NOTE: The initial version of this comment hypothesised that this may help with some recent false positives from malware scanners. This hypothesis proved wrong. Sorry for the distraction.
add fut/back compat tests for implied trait bounds

the `guard` test was tested to cause a segfault with `-Zchalk`, very nice

cc `@nikomatsakis` rust-lang#44491 rust-lang#25860
…=lnicola

⬆️ rust-analyzer

r? `@ghost`
@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 Feb 8, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Feb 8, 2022

📌 Commit 64e706c 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 Feb 8, 2022
@bors
Copy link
Contributor

bors commented Feb 8, 2022

⌛ Testing commit 64e706c with merge 77db130bd3875a18f5d9122c53b24a56791c00c4...

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-stable failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[TIMING] ToolBuild { compiler: Compiler { stage: 0, host: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } }, target: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None }, tool: "lint-docs", path: "src/tools/lint-docs", mode: ToolBootstrap, is_optional_tool: false, source_type: InTree, extra_features: [] } -- 5.448
[TIMING] LintDocs { compiler: Compiler { stage: 0, host: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } }, target: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } } -- 0.000
warning: the code example in lint `stable_features` in /checkout/compiler/rustc_lint_defs/src/builtin.rs failed to generate the expected output: did not find lint `stable_features` in output of example, got:

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> lint_example.rs:1:1
1 | #![feature(test_accepted_feature)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute
  |
  = help: the feature `test_accepted_feature` has been stable since 1.0.0 and no longer requires an attribute to enable
  = help: the feature `test_accepted_feature` has been stable since 1.0.0 and no longer requires an attribute to enable


error: aborting due to previous error


For more information about this error, try `rustc --explain E0554`.

warning: the code example in lint `unused_allocation` in /checkout/compiler/rustc_lint/src/unused.rs failed to generate the expected output: did not find lint `unused_allocation` in output of example, got:

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> lint_example.rs:1:1
1 | #![feature(box_syntax)]
  | ^^^^^^^^^^^^^^^^^^^^^^^


---
[TIMING] RustcBook { compiler: Compiler { stage: 2, host: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } } } -- 0.000
Generating lint docs (x86_64-unknown-linux-gnu)
error: failed to test example in lint docs for `stable_features` in /checkout/compiler/rustc_lint_defs/src/builtin.rs:784: did not find lint `stable_features` in output of example, got:

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> lint_example.rs:1:1
1 | #![feature(test_accepted_feature)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute
  |
  = help: the feature `test_accepted_feature` has been stable since 1.0.0 and no longer requires an attribute to enable
---

For more information about this error, try `rustc --explain E0554`.


This error was generated by the lint-docs tool.
This tool extracts documentation for lints from the source code and places
them in the rustc book. See the declare_lint! documentation
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/macro.declare_lint.html
for an example of the format of documentation this tool expects.


To re-run these tests, run: ./x.py test --keep-stage=0 src/tools/lint-docs
The --keep-stage flag should be used if you have already built the compiler

@bors
Copy link
Contributor

bors commented Feb 8, 2022

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 8, 2022
@matthiaskrgr matthiaskrgr deleted the rollup-drdtfrp 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
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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.