Auto merge of #98840 - cjgillot:span-inline-ctxt, r=wesleywiser
Inline SyntaxContext in both encoded span representation.
The current interned representation for spans does not use the `ctxt_or_zero: u16` field. This PR proposes to use this field to store the `SyntaxContext` of the interned span instead. When `ctxt_or_zero` and the interned span's `ctxt` don't match, the inlined one takes precedence.
This allows to implement `Span::ctxt` and `Span::with_ctxt` with much less probability to access the interner. Those functions are used a lot for hygiene, so this may be worth it.
Auto merge of #102139 - Dylan-DPC:rollup-ljlipt8, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #101598 (Update rustc's information on Android's sanitizers)
- #102036 (Remove use of `io::ErrorKind::Other` in std)
- #102037 (Make cycle errors recoverable)
- #102069 (Skip `Equate` relation in `handle_opaque_type`)
- #102076 (rustc_transmute: fix big-endian discriminants)
- #102107 (Add missing space between notable trait tooltip and where clause)
- #102119 (Fix a typo “pararmeter” in error message)
- #102131 (Added which number is computed in compute_float.)
The original comment was very elaborate but ultimately did not mention at all what is being computed using parameters `w, q`, only referencing an external article for the algorithm.
Rollup merge of #102076 - cuviper:transmute-discr-endian, r=jackh726
rustc_transmute: fix big-endian discriminants
I noticed that some new tests were failing in Fedora on s390x only, which usually means there's a problem with big-endian, and sure enough there's a FIXME(``@jswrenn)`` for that in `rustc_transmute`. This patch implements the appropriate consideration for target endianness, rather than using native (host) endian.
Rollup merge of #102037 - jyn514:normalize-docs, r=lcnr
Make cycle errors recoverable
In particular, this allows rustdoc to recover from cycle errors when normalizing associated types for documentation.
In the past, ```@jackh726``` has said we need to be careful about overflow errors: https://github.com/rust-lang/rust/pull/91430#issuecomment-983997013
> Off the top of my head, we definitely should be careful about treating overflow errors the same as
"not implemented for some reason" errors. Otherwise, you could end up with behavior that is
different depending on recursion depth. But, that might be context-dependent.
But cycle errors should be safe to unconditionally report; they don't depend on the recursion depth, they will always be an error whenever they're encountered.
Helps with https://github.com/rust-lang/rust/issues/81091.
Rollup merge of #101598 - chriswailes:sanitizers, r=nagisa,eholk
Update rustc's information on Android's sanitizers
This patch updates sanitizer support definitions for Android inside the compiler. It also adjusts the logic to make sure no pre-built sanitizer runtime libraries are emitted as these are instead provided dynamically on Android targets.
Auto merge of #100980 - compiler-errors:normalize-opaque-w-bound-vars, r=lcnr
Normalize opaques w/ bound vars
First, we reenable normalization of opaque types with escaping late bound regions to fix rust-lang/miri#2433. This essentially reverts #89285.
Second, we mitigate the perf regression found in #88862 by simplifying the way that we relate (sub and eq) GeneratorWitness types.
This relies on the fact that we construct these GeneratorWitness types somewhat particularly (with all free regions found in the witness types replaced with late bound regions) -- but those bound regions really should be treated as existential regions, not universal ones. Those two facts leads me to believe that we do not need to use the full `higher_ranked_sub` machinery to relate two generator witnesses. I'm pretty confident that this is correct, but I'm glad to discuss this further.
9 commits in f62e93c28323ed9637d0a205a0c256498674a509..a7cdac33ca7356ad49d5c2b5e2c5010889b33eee
2022-08-28 10:01:28 -0700 to 2022-09-19 17:39:58 -0700
- Clarify wording for references. (rust-lang/reference#1223)
- Update Unicode reference to match rustc implementation (rust-lang/reference#1271)
- Add documentation for raw-dylib and link_ordinal (rust-lang/reference#1244)
- Specify guarantees for repr(rust) structs (rust-lang/reference#1152)
- Classify AsyncBlockExpression as ExpressionWithoutBlock (rust-lang/reference#1268)
- Update closure-expr.md (rust-lang/reference#1269)
- Clarify that 0 is a valid multiple of a type's alignment (rust-lang/reference#1260)
- Remove `ne` from derive example (rust-lang/reference#1264)
- Clarify reference on async blocks (rust-lang/reference#1262)
## book
6 commits in 0a5421ceb238357b3634fb75234eba4d1dad643c..f1e5ad844d0c61738006cdef26227beeb136948e
2022-08-28 19:51:04 -0400 to 2022-09-19 09:48:21 -0400
- Fix punctuation in ch05-02
- Ownership move chapter link fix
- Wrong listing number
- Reword text around box
- `Box<T>` instead of "box"
- Update Clippy output in Appendix D
15 commits in 04892c1a6fc145602ac7367945fda9d4ee83c9fb..f587d6e7cddeaa3cf0a33ec1e368df1a408fa0aa
2022-08-29 20:07:51 +0200 to 2022-09-20 07:43:59 +0900
- Update stability guide to use CURRENT_RUSTC_VERSION (rust-lang/rustc-dev-guide#1468)
- Add a note about building `rust-analyzer-proc-macro-srv` (rust-lang/rustc-dev-guide#1467)
- Link from "implementing to new features" to mcp.md (rust-lang/rustc-dev-guide#1465)
- remove stray **
- Explain the new valtree system for type level constants. (rust-lang/rustc-dev-guide#1097)
- fix typos and formatting
- Say "bootstrap" instead of "rustbuild"; the latter is not explained anywhere and is not much more clear.
- Rewrite the section on passing flags to subcommands
- Remove the diagram of all outputs generated by x.py
- "symbol names" => ABI
- Add symbol-addition to the how-to for new features (rust-lang/rustc-dev-guide#1457)
- Fix typo (rust-lang/rustc-dev-guide#1459)
- Document multipart_suggestion derive on SessionSubdiagnostic
- Add reference for updating Windows PATH and fix typo
- Update for removal of RLS (rust-lang/rustc-dev-guide#1450)
This rule was added in 88fe6dfa31a1bee49090dc72c537c5cd7bd632f4 to assist in position the hide/show togges on methods. This is no longer needed, because these toggles are no longer implemented as absolutely positioned links nested inside headers.
Rollup merge of #102032 - andrewpollack:bad-signal-compiler-tests, r=tmandry
Adding ignore fuchsia tests for signal interpretation cases
Tests where Signal interpreting is required. Since Fuchsia currently does not return signals of type `libc::SIGSEGV` etc., instead, use generalized `!status.success()` case.
Rollup merge of #102030 - est31:tidy_walk_no_reexport, r=Mark-Simulacrum
Don't crate-locally reexport walk functions in tidy
I've moved the walk functions into their own module in #100591 and didn't want to make changing the paths everywhere in tidy part of the PRs diff, so I just reexported the functions locally. This PR removes the crate-local reexport and instead does module level reexports. I'm not sure how much it's worth it and whether the new state is better, idk. Feel free to have any opinion on this.
Rollup merge of #101952 - Mark-Simulacrum:missing-fallback, r=ehuss
Avoid panicking on missing fallback
This just prints a message but continues on if a fallback is missing, which can happen when we're building a partial set of builders and producing a dev-static build from it (e.g., when no Apple builder runs at all).
Probably the more extensive fix is to allow the build-manifest invoker to specify the expected set of targets & hosts, but that's a far more extensive change. The main risk from this is that we accidentally start falling back to linux docs across all platforms without noticing. I'm not sure that we can do much about that though at this time.
cc `@ehuss` since IIRC you participated in adding this system
This comes up when building a test nightly from a try build, e.g., https://github.com/rust-lang/rust/pull/101855#issuecomment-1250123298. For now I'm going to manually cherry pick this onto that PR for testing purposes.
Auto merge of #101558 - JhonnyBillM:session-diagnostic-to-diagnostic-handler-refactor, r=davidtwco
Move and rename `SessionDiagnostic` & `SessionSubdiagnostic` traits and macros
After PR #101434, we want to:
- [x] Move `SessionDiagnostic` to `rustc_errors`.
- [x] Add `emit_` methods that accept `impl SessionDiagnostic` to `Handler`.
- [x] _(optional)_ Rename trait `SessionDiagnostic` to `DiagnosticHandler`.
- [x] _(optional)_ Rename macro `SessionDiagnostic` to `DiagnosticHandler`.
- [x] Update Rustc Dev Guide and Docs to reflect these changes. https://github.com/rust-lang/rustc-dev-guide/pull/1460
Now I am having build issues getting the compiler to build when trying to rename the macro.
<details>
<summary>See diagnostics errors and context when building.</summary>
```
error: diagnostics should only be created in `SessionDiagnostic`/`AddSubdiagnostic` impls
--> compiler/rustc_attr/src/session_diagnostics.rs:13:10
|
13 | #[derive(DiagnosticHandler)]
| ^^^^^^^^^^^^^^^^^ in this derive macro expansion
|
::: /Users/jhonny/.cargo/registry/src/github.com-1ecc6299db9ec823/synstructure-0.12.6/src/macros.rs:94:9
|
94 | / pub fn $derives(
95 | | i: $crate::macros::TokenStream
96 | | ) -> $crate::macros::TokenStream {
| |________________________________________- in this expansion of `#[derive(DiagnosticHandler)]`
|
note: the lint level is defined here
--> compiler/rustc_attr/src/lib.rs:10:9
|
10 | #![deny(rustc::diagnostic_outside_of_impl)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
And also this one:
```
error: diagnostics should only be created in `SessionDiagnostic`/`AddSubdiagnostic` impls
--> compiler/rustc_attr/src/session_diagnostics.rs:213:32
|
213 | let mut diag = handler.struct_span_err_with_code(
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
> **Note**
> Can't find where this message is coming from, because you can see in [this experimental branch](https://github.com/JhonnyBillM/rust/tree/experimental/trying-to-rename-session-diagnostic-macro) that I updated all errors and diags to say:
> error: diagnostics should only be created in **`DiagnosticHandler`**/`AddSubdiagnostic` impls
> and not:
> error: diagnostics should only be created in **`SessionDiagnostic`**/`AddSubdiagnostic` impls
</details>
I tried building the compiler in different ways (playing with the stages etc), but nothing worked.
## Question
**Do we need to build or do something different when renaming a macro and identifiers?**
For context, see experimental commit https://github.com/JhonnyBillM/rust/commit/f2193a98b44db3f2af77a878824b152cdf0d34a5 where the macro and symbols are renamed, but it doesn't compile.
Rollup merge of #102058 - mqudsi:path_extension_docs, r=thomcc
Clarify Path::extension() semantics in docs abstract
State up-front and center what shape the returned extension will have, without making the user read through the description and examples.
This is a doc-only change. There are no changes to the API contract and the clarification is in line with what was already stated/promised in the existing doc text - just clarified, summarized, and served bright and early.
Rationale: Various frameworks and libraries for different platforms have their different conventions as to whether an "extension" is ".ext" or just "ext" and anyone that's had to deal with this ambiguity in the past is always double- or triple-checking to make sure the function call returns an extension that matches the expected semantics. Offer the answer to this important question right off the bat instead of making them dig to find it.
Rollup merge of #102045 - RalfJung:const-prop-regression-fix, r=oli-obk
fix ConstProp handling of written_only_inside_own_block_locals
Fixes a regression introduced by https://github.com/rust-lang/rust/pull/100239, which adds an early return and thus skips some code in `visit_terminator` that must be run for soundness.
Rollup merge of #102031 - andrewpollack:compiler-tests-backtrace, r=tmandry
Adding ignore fuchsia tests for Backtrace, ErrorKind cases
Tests where Backtrace parses are required (invalid since Fuchsia backtraces are not symbolized), and test where ErrorKind is not properly translated from a Fuchsia-style to Unix-style error code
changelog: Enhancement: [`nonstandard_macro_braces`]: Now includes `matches!()` in the default lint config
[#9471](https://github.com/rust-lang/rust-clippy/pull/9471)
Auto merge of #101329 - QuinnPainter:armv5te-targets, r=nagisa
Add armv5te-none-eabi and thumbv5te-none-eabi targets
Creates two new Tier 3 targets, `armv5te-none-eabi` and `thumbv5te-none-eabi`. They are for the same target architecture (armv5te), but one defaults to the A32 instruction set and the other defaults to T32. Based on the existing `armv4t-none-eabi` and `thumbv4t-none-eabi` targets.
My particular use case for these targets is Nintendo DS homebrew, but they should be usable for any armv5te system.
Going through the Tier 3 target policy:
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
That will be me.
> Targets must use naming consistent with any existing targets.
Naming is consistent with previous targets.
>> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility.
No ambiguity here.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
Doesn't create any legal issues.
>> The target must not introduce license incompatibilities.
This doesn't introduce any new licenses.
>> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Yep.
>> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
No new license requirements.
>> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries.
Everything this uses is FOSS, no proprietary required.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
OK.
>> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
OK.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
This is a bare-metal target with only support for `core` (and `alloc`, if the user provides an allocator).
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
Documentation has been added.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
OK.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
OK.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
This doesn't break any other targets.
>> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
Auto merge of #9505 - mikerite:fix-9504-2, r=dswij
Fix ICE in `unnecessary_to_owned`
Fixes #9504
Compiler generated call `into_future` nodes return empty substs which we need when checking it's predicates. Handle this by simply exitting when we encounter one. This change introduces false negatives in place of the ICEs.
Michael Wright [Wed, 21 Sep 2022 05:02:52 +0000 (07:02 +0200)]
Fix ICE in `unnecessary_to_owned`
Fixes #9504
Compiler generated call `into_iter` nodes return empty substs
which we need when checking it's predicates. Handle this by
simply exitting when we encounter one. This change introduces
false negatives in place of the ICEs.
Auto merge of #100096 - compiler-errors:fn-return-must-be-sized, r=jackh726
a fn pointer doesn't implement `Fn`/`FnMut`/`FnOnce` if its return type isn't sized
I stumbled upon #83915 which hasn't received much attention recently, and I wanted to revive it since this is one existing soundness hole that seems pretty easy to fix.
I'm not actually sure that the [alternative approach described here](https://github.com/rust-lang/rust/pull/83915#issuecomment-823643322) is sufficient, given the `src/test/ui/function-pointer/unsized-ret.rs` example I provided below. Rebasing the branch mentioned in that comment and testing that UI test, it seems that we actually end up only observing that `str: !Sized` during monomorphization, whereupon we ICE. Even if we were to fix that ICE, ideally we'd be raising an error that a fn pointer is being used badly during _typecheck_ instead of monomorphization, hence adapting the original approach in #83915.
I am happy to close this if people would prefer we rebase the original PR and land that -- I am partly opening to be annoying and get people thinking about this unsoundness again :heart: :smile_cat:
cc: `@estebank` and `@nikomatsakis`
r? types
Here's a link to the thread: https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/PR.20.2383915/near/235421351 for more context.
It's now much more like the `-Zhir-stats` output.
- Each line is preceded with `meta-stats`, which makes the provenance
clearer and allows filtering of the output.
- Sections are now sorted in reverse order of size.
- Column headings avoid the need to repeat the word "bytes" on every line.
- Long numbers now have `_` separators for easier reading.
- Consistent use of '-' within section labels, rather than a mix of '-',
'_', and ' '.
The code itself is shorter and easier to read thanks to:
- the `stat` macro, which encapsulates each section's encoding, avoids
some boilerplate, and removes the need for some low-value comments;
- the `stats` vector, which replaces dozens of local variables.
Auto merge of #100214 - scottmcm:strict-range, r=thomcc
Optimize `array::IntoIter`
`.into_iter()` on arrays was slower than it needed to be (especially compared to slice iterator) since it uses `Range<usize>`, which needs to handle degenerate ranges like `10..4`.
This PR adds an internal `IndexRange` type that's like `Range<usize>` but with a safety invariant that means it doesn't need to worry about those cases -- it only handles `start <= end` -- and thus can give LLVM more information to optimize better.
I added one simple demonstration of the improvement as a codegen test.
(`vec::IntoIter` uses pointers instead of indexes, so doesn't have this problem, but that only works because its elements are boxed. `array::IntoIter` can't use pointers because that would keep it from being movable.)
This rule was added in 88fe6dfa31a1bee49090dc72c537c5cd7bd632f4 to assist
in position the hide/show togges on methods. This is no longer needed,
because these toggles are no longer implemented as absolutely positioned
links nested inside headers.
Mark Rousskov [Sat, 17 Sep 2022 22:13:59 +0000 (18:13 -0400)]
Avoid panicking on missing fallback
This just prints a message but continues on if a fallback is missing,
which can happen when we're building a partial set of builders and
producing a dev-static build from it (e.g., when no Apple builder runs
at all).
Probably the more extensive fix is to allow the build-manifest invoker
to specify the expected set of targets & hosts, but that's a far more
extensive change. The main risk from this is that we accidentally start
falling back to linux docs across all platforms without noticing. I'm
not sure that we can do much about that though at this time.
Auto merge of #100581 - joboet:sync_rwlock_everywhere, r=thomcc
std: use `sync::RwLock` for internal statics
Since `sync::RwLock` is now `const`-constructible, it can be used for internal statics, removing the need for `sys_common::StaticRwLock`. This adds some extra allocations on platforms which need to box their locks (currently SGX and some UNIX), but these will become unnecessary with the lock improvements tracked in #93740.
Chris Wailes [Thu, 8 Sep 2022 23:33:44 +0000 (16:33 -0700)]
Update rustc's information on Android's sanitizers
This patch updates sanitizier support definitions for Android inside the
compiler. It also adjusts the logic to make sure no pre-built sanitizer
runtime libraries are emitted as these are instead provided dynamically
on Android targets.
Michael Howell [Tue, 20 Sep 2022 17:13:02 +0000 (10:13 -0700)]
Rollup merge of #102038 - jyn514:rustdoc-normalize-test, r=compiler-errors
Make the `normalize-overflow` rustdoc test actually do something
Since https://github.com/rust-lang/rust/pull/88679, rustdoc doesn't load crates eagerly. Add an explicit `extern crate` item to make sure the crate is loaded and the bug reproduces.
You can verify this fix by adding `// compile-flags: -Znormalize-docs` and running the test to make sure it gives an error.
For this rule to have an actual effect, the border-bottom width needs specified, elsewhere, without also specifying the color. This doesn't happen. Ever since 88b137d5fe0cbe28dab4f9af61045c726f831872, every spot where headers get a border assigned to them also assigns the color.
Michael Howell [Tue, 20 Sep 2022 17:13:01 +0000 (10:13 -0700)]
Rollup merge of #102027 - notriddle:notriddle/docblock-item-decl, r=GuillaumeGomez
rustdoc: remove `docblock` class from `item-decl`
This class was originally added in 73b97c7e7c9cfac4dfa4804654b1db6ab687b589 to support hiding and showing the item, because `main.js` went through all `docblock` elements in the DOM and added toggles to them.
projects / rust.git / log