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 8 pull requests #121142

Merged
merged 25 commits into from Feb 15, 2024
Merged

Rollup of 8 pull requests #121142

merged 25 commits into from Feb 15, 2024

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

udoprog and others added 25 commits January 28, 2024 15:57
These would incorrectly leave `current` as `None` after a failed attempt
to remove an element (due to the cursor already being at the start/end).
up to now, it had been assumed the stack guard setting default is not
touched in the field but some user might just want to disable it or
increase it. checking it once at runtime should be enough.
LLVM 18 requires the evex512 feature to allow use of zmm registers.
LLVM automatically sets it when using a generic CPU, but not when
`-C target-cpu` is specified. This will result either in backend
legalization crashes, or code unexpectedly using ymm instead of
zmm registers.

For now, make sure that `avx512*` features imply `evex512`. Long
term we'll probably have to deal with the AVX10 mess somehow.
When encountering a verbose/multipart suggestion that has changes
that are only caused by different capitalization of ASCII letters that have
little differenciation, expand the message to highlight that fact (like we
already do for inline suggestions).

The logic to do this was already present, but implemented incorrectly.
`cook_lexer_literal` can emit an error about an invalid int literal but
then return a non-`Err` token. And then `integer_lit` has to account for
this to avoid printing a redundant error message.

This commit changes `cook_lexer_literal` to return `Err` in that case.
Then `integer_lit` doesn't need the special case, and
`LitError::LexerError` can be removed.
This will be helpful for subsequent commits.
And use the result in `cook_common` to decide whether to return an error
token.
This mostly works well, and eliminates a couple of delayed bugs.

One annoying thing is that we should really also add an
`ErrorGuaranteed` to `proc_macro::bridge::LitKind::Err`. But that's
difficult because `proc_macro` doesn't have access to `ErrorGuaranteed`,
so we have to fake it.
To avoid some unwrapping.
…om-raw, r=m-ou-se

Document requirements for unsized {Rc,Arc}::from_raw

This seems to be implied due to these types supporting operation-less unsized coercions. Taken together with the [established behavior of a wide to thin pointer cast](rust-lang/reference#1451) it would enable unsafe downcasting of these containers.

Note that the term "data pointer" is adopted from rust-lang/rfcs#3559

See also this [internals thread](https://internals.rust-lang.org/t/can-unsafe-smart-pointer-downcasts-be-correct/20229/2).
…, r=m-ou-se

Fix BTreeMap's Cursor::remove_{next,prev}

These would incorrectly leave `current` as `None` after a failed attempt to remove an element (due to the cursor already being at the start/end).
…pages_fbsd, r=m-ou-se

std::thread update freebsd stack guard handling.

up to now, it had been assumed the stack guard setting default is not touched in the field but some user might just want to disable it or increase it. checking it once at runtime should be enough.
Implicitly enable evex512 if avx512 is enabled

LLVM 18 requires the evex512 feature to allow use of zmm registers. LLVM automatically sets it when using a generic CPU, but not when `-C target-cpu` is specified. This will result either in backend legalization crashes, or code unexpectedly using ymm instead of zmm registers.

For now, make sure that `avx512*` features imply `evex512`. Long term we'll probably have to deal with the AVX10 mess somehow.

Fixes rust-lang#121081.

r? `@Amanieu`
…iler-errors

Ignore unsized types when trying to determine the size of the original type

Fixes rust-lang#121074 a regression from rust-lang#118983
…, r=michaelwoerister

Fix msg for verbose suggestions with confusable capitalization

When encountering a verbose/multipart suggestion that has changes that are only caused by different capitalization of ASCII letters that have little differenciation, expand the message to highlight that fact (like we already do for inline suggestions).

The logic to do this was already present, but implemented incorrectly.
…-errors

Continue compilation even if inherent impl checks fail

We should not be hiding errors behind unrelated errors
…ease

Add `ErrorGuaranteed` to `ast::LitKind::Err`, `token::LitKind::Err`.

Similar to recent work doing the same for `ExprKind::Err` (rust-lang#120586) and `TyKind::Err` (rust-lang#121109).

r? `@oli-obk`
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=5 rollup=never

@rustbot rustbot added O-unix Operating system: Unix-like 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. labels Feb 15, 2024
@rustbot rustbot added the rollup A PR which is a rollup label Feb 15, 2024
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=5 rollup=never

@bors
Copy link
Contributor

bors commented Feb 15, 2024

📌 Commit 06f53dd 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 Feb 15, 2024
@bors
Copy link
Contributor

bors commented Feb 15, 2024

⌛ Testing commit 06f53dd with merge cbddf31...

@bors
Copy link
Contributor

bors commented Feb 15, 2024

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing cbddf31 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 15, 2024
@bors bors merged commit cbddf31 into rust-lang:master Feb 15, 2024
12 checks passed
@rustbot rustbot added this to the 1.78.0 milestone Feb 15, 2024
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#120449 Document requirements for unsized {Rc,Arc}::from_raw 05ae9442e08a01250cdd5278561d55e03c4aae9f (link)
#120505 Fix BTreeMap's Cursor::remove_{next,prev} 60651fe1c914429a129428d295af8f8a133b9106 (link)
#120672 std::thread update freebsd stack guard handling. f20c85e252790974033cbabefc29165b0e8027cb (link)
#121088 Implicitly enable evex512 if avx512 is enabled cb38e533dfbb4fad1e1c7811d47c6af07018bd10 (link)
#121104 Ignore unsized types when trying to determine the size of t… 4d3276c8952ee7166acb3b7ed5b2b62c699314f8 (link)
#121107 Fix msg for verbose suggestions with confusable capitalizat… 250886f9efddb1bd341ec434f12b8aa872fce6d1 (link)
#121113 Continue compilation even if inherent impl checks fail 45e7d1aa4c795199edd5bb5252bd9a1f8b3304f5 (link)
#121120 Add ErrorGuaranteed to ast::LitKind::Err, `token::LitKi… 09494a05704450f8618c3c0b4de25a81f61e55f9 (link)

previous master: 62fb0db9a5

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (cbddf31): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-6.8% [-6.8%, -6.8%] 1
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.8% [2.8%, 2.8%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.8% [2.8%, 2.8%] 1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-5.0% [-5.0%, -5.0%] 1
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 638.252s -> 636.031s (-0.35%)
Artifact size: 306.28 MiB -> 306.32 MiB (0.01%)

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. O-unix Operating system: Unix-like 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. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet