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 10 pull requests #104152

Closed
wants to merge 33 commits into from

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

chenyukang and others added 30 commits October 25, 2022 21:16
These have been bugging me for a while.

- `literal_text`: `src` is also used and is shorter and better.
- `first_char`: used even when "first" doesn't make sense; `c` is
  shorter and better.
- `curr`: `c` is shorter and better.
- `unescaped_char`: `result` is also used and is shorter and better.
- `second_char`: these have a single use and can be elided.
There is some subtlety here.
It's passed to numerous places where we just need an `is_byte` bool.
Passing the bool avoids the need for some assertions.

Also rename `is_bytes()` as `is_byte()`, to better match `Mode::Byte`,
`Mode::ByteStr`, and `Mode::RawByteStr`.
There are three kinds of "byte" literals: byte literals, byte string
literals, and raw byte string literals. None are allowed to have
non-ASCII chars in them.

Two `EscapeError` variants exist for when that constraint is violated.
- `NonAsciiCharInByte`: used for byte literals and byte string literals.
- `NonAsciiCharInByteString`: used for raw byte string literals.

As a result, the messages for raw byte string literals use different
wording, without good reason. Also, byte string literals are incorrectly
described as "byte constants" in some error messages.

This commit eliminates `NonAsciiCharInByteString` so the three cases are
handled similarly, and described correctly. The `mode` is enough to
distinguish them.

Note: Some existing error messages mention "byte constants" and some
mention "byte literals". I went with the latter here, because it's a
more correct name, as used by the Reference.
Remove a low-value comment, remove a duplicate comment, and correct a
third comment.
It deals with eight cases: ints, floats, and the six quoted types
(char/byte/strings). For ints and floats we have an early return, and
the other six types fall through to the code at the end, which makes the
function hard to read.

This commit rearranges things to avoid the early returns.
It has a single callsite, and is fairly small. The `Float` match arm
already has base-specific checking inline, so this makes things more
consistent.
It's easy to just use `unescape_literal` + `byte_from_char`.
This option prints all supported values for -Csplit-debuginfo=.., i.e.
only stable ones on stable/beta and all of them on nightly/dev.
fix: lint against the functions `LintContext::{lookup_with_diagnostics,lookup,struct_span_lint,lint}`, `TyCtxt::struct_lint_node`, `LintLevelsBuilder::struct_lint`.
The `usize` isn't needed in the error case.
…-hang, r=jackh726,wesleywiser

Avoid possible infinite  loop when next_point reaching the end of file

Fixes rust-lang#103451
If we return a span with `lo` = `hi`, `span_to_snippet` will always get `Ok("")`, which may introduce infinite loop if we don't care.

This PR make `find_width_of_character_at_span` return `width` with 1, so that `span_to_snippet` will get an `Err`.
…Simulacrum

Upgrade cc for working is_flag_supported on cross-compiles

rust-lang#85806 fixed unwind v.s gcc support on later Android ndks using `is_flag_supported`. However, due to rust-lang/cc-rs#675, this didn't work properly on cross-compiles. rust-lang/cc-rs@3eeb50b fixes this, and was released in cc 1.0.74, hence the upgrade
…=matklad

Unescaping cleanups

Some code improvements, and some error message improvements.

Best reviewed one commit at a time.

r? ``@matklad``
…ce, r=Mark-Simulacrum

Don't intra linkcheck reference

This removes the reference from the intra-doc link checks. This causes problems if any of the reference content needs to change, it causes the linkchecker to break. The reference has its own broken link check (https://github.com/rust-lang/reference/tree/master/style-check) which uses pulldown-cmark on the source to find actual broken links (instead of false-positives like this regex does).

I think the intra-doc link check could potentially be removed completely, since I think rustdoc is now checking for them well enough. However, it may serve as a decent regression check.
Place config.toml in current working directory if config not found

Fixes an issue where bootsrapping a Rust build would place `config.toml` in `{src_root}` rather than the current working directory

rust-lang#103697
Add split-debuginfo print option

This option prints all supported values for `-Csplit-debuginfo=..`, i.e. only stable ones on stable/beta and all of them on nightly/dev.

Motivated by 1.65.0 regression causing builds with the following entry in `Cargo.toml` to fail on Windows:
```toml
[profile.dev]
split-debuginfo = "unpacked"
```

See rust-lang/cargo#11347 for details.

This will lead to closing rust-lang#103976.
…mpls, r=compiler-errors

Fix `const_fn_trait_ref_impl`, add test for it

rust-lang#99943 broke `#[feature(const_fn_trait_ref_impl)]`, this PR fixes this and adds a test for it.

r? ```@fee1-dead```
…th, r=notriddle

Fix invalid background-image file name

This is a follow-up of rust-lang#101702.

Apparently the image hash was the wrong one. You can see the error in https://doc.rust-lang.org/nightly/core/primitive.u16.html?search=hello too.

I really need to check if I can adds check for resources load errors in `browser-ui-test`.

cc `````@jsha`````
r? `````@notriddle`````
…=davidtwco

fix: lint against lint functions

Add `#[rustc_lint_diagnostics]` to lint functions missing them. From [this discussion](rust-lang#101138 (comment)).

r? ``@davidtwco``
…pnkfelix

Clarify licensing situation of MPSC and SPSC queue

Originally, these two files were licensed under the `BSD-2-Clause` license, as they were based off sample code on a blog licensing those snippets under that license:

* `library/std/src/sync/mpsc/mpsc_queue.rs`
* `library/std/src/sync/mpsc/spsc_queue.rs`

In 2017 though, the author of that blog agreed to relicense their code under the standard `MIT OR Apache-2.0` license in rust-lang#42149. This PR clarifies the situation in the files by expanding the comment at the top of the file.

r? `@pnkfelix`
@rustbot rustbot added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 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. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Nov 8, 2022
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=10 rollup=never

@bors
Copy link
Contributor

bors commented Nov 8, 2022

📌 Commit c421dac has been approved by GuillaumeGomez

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 8, 2022
@bors
Copy link
Contributor

bors commented Nov 8, 2022

⌛ Testing commit c421dac with merge cbe107883d6d53651fbc0b25e37ea7ed6a0ea76d...

@bors
Copy link
Contributor

bors commented Nov 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 Nov 8, 2022
@GuillaumeGomez GuillaumeGomez deleted the rollup-5ott3lo branch November 8, 2022 19:37
@rust-log-analyzer
Copy link
Collaborator

The job dist-aarch64-msvc failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] typenum test:false 1.073
   Compiling annotate-snippets v0.9.1
The following warnings were emitted during compilation:

warning: The MSVC ARM assemblers do not support -D flags
error: failed to run custom build command for `psm v0.1.16`

Caused by:
  process didn't exit successfully: `D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage1-rustc\release\build\psm-c0ca29d29f3e8391\build-script-build` (exit code: 1)
  process didn't exit successfully: `D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage1-rustc\release\build\psm-c0ca29d29f3e8391\build-script-build` (exit code: 1)
  --- stdout
  OPT_LEVEL = Some("3")
  TARGET = Some("aarch64-pc-windows-msvc")
  HOST = Some("x86_64-pc-windows-msvc")
  cargo:rerun-if-env-changed=CC_aarch64-pc-windows-msvc
  CC_aarch64-pc-windows-msvc = None
  cargo:rerun-if-env-changed=CC_aarch64_pc_windows_msvc
  CC_aarch64_pc_windows_msvc = None
  cargo:rerun-if-env-changed=TARGET_CC
  TARGET_CC = None
  cargo:rerun-if-env-changed=CC
  CC = Some("D:/a/rust/rust/citools/clang-rust/bin/clang-cl.exe")
  cargo:rerun-if-env-changed=CFLAGS_aarch64-pc-windows-msvc
  CFLAGS_aarch64-pc-windows-msvc = None
  cargo:rerun-if-env-changed=CFLAGS_aarch64_pc_windows_msvc
  CFLAGS_aarch64_pc_windows_msvc = None
  cargo:rerun-if-env-changed=TARGET_CFLAGS
  TARGET_CFLAGS = None
  cargo:rerun-if-env-changed=CFLAGS
  CFLAGS = None
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CARGO_CFG_TARGET_FEATURE = Some("crt-static,llvm14-builtins-abi,neon")
  DEBUG = Some("false")
  DEBUG = Some("false")
  cargo:rustc-cfg=asm
  cargo:warning=The MSVC ARM assemblers do not support -D flags
  running: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Enterprise\\VC\\Tools\\MSVC\\14.29.30133\\bin\\HostX64\\arm64\\armasm64.exe" "-nologo" "-o" "D:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage1-rustc\\aarch64-pc-windows-msvc\\release\\build\\psm-995d162fe6f0b1f5\\out\\src/arch/aarch64_armasm.o" "--" "src/arch/aarch64_armasm.asm"
  error A2029: unknown command-line argument or argument value --

   Usage:      armasm [<options>] sourcefile objectfile
               armasm [<options>] -o objectfile sourcefile
               armasm -h              for help
  exit code: 1

  --- stderr



  error occurred: Command "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Enterprise\\VC\\Tools\\MSVC\\14.29.30133\\bin\\HostX64\\arm64\\armasm64.exe" "-nologo" "-o" "D:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage1-rustc\\aarch64-pc-windows-msvc\\release\\build\\psm-995d162fe6f0b1f5\\out\\src/arch/aarch64_armasm.o" "--" "src/arch/aarch64_armasm.asm" with args "armasm64.exe" did not execute successfully (status code exit code: 1).

warning: build failed, waiting for other jobs to finish...
[RUSTC-TIMING] ppv_lite86 test:false 0.486
[RUSTC-TIMING] indexmap test:false 0.710

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-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet