Both functions do some modifying of streams using `make_mut`:
- `push` sometimes glues the first token of the next stream to the last
token of the first stream.
- `build` appends tokens to the first stream.
By doing all of this in the one place, things are simpler. The first
stream can be modified in both ways (if necessary) in the one place, and
any next stream with the first token removed doesn't need to be stored.
Fix `SourceScope` for `if let` bindings.
Fixes#97799.
I'm not sure how to test this properly, is there any way to observe the difference in behavior apart from `ui` tests? I'm worried that they would be overlooked in the case of a regression.
It's a weird function: it lets you modify the token stream in the middle
of iteration. There is only one call site, and it is only used for the
rare `ProceduralMasquerade` legacy case.
Make debug_triple depend on target json file content rather than file path
This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation.
This should fix https://github.com/Rust-for-Linux/linux/issues/792 (cc ``@ojeda)``
Stabilize `Path::try_exists()` and improve doc
This stabilizes the `Path::try_exists()` method which returns
`Result<bool, io::Error>` instead of `bool` allowing handling of errors
unrelated to the file not existing. (e.g permission errors)
Along with the stabilization it also:
* Warns that the `exists()` method is error-prone and suggests to use
the newly stabilized one.
* Suggests it instead of `metadata()` to handle errors.
* Mentions TOCTOU bugs to avoid false assumption that `try_exists()` is
completely safe fixed version of `exists()`.
* Renames the feature of still-unstable `std::fs::try_exists()` to
`fs_try_exists` to avoid name conflict.
The tracking issue #83186 remains open to track `fs_try_exists`.
Most futures don't go through this code path, because they're caught by
`maybe_note_obligation_cause_for_async_await`. But all generators do,
and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses.
At some point, we may want to consider unifying this with the code for `maybe_note_async_await`,
so that `async_await` notes all parent constraints, and `note_obligation` can point to yield points.
But both functions are quite complicated, and it's not clear to me how to combine them;
this seems like a good incremental improvement.
Rollup of 5 pull requests
Successful merges:
- #98105 (rustdoc: remove tuple link on round braces)
- #98136 (Rename `impl_constness` to `constness`)
- #98146 (Remove --memory-init-file flag when linking with Emscripten)
- #98219 (Skip late bound regions in GATSubstCollector)
- #98233 (Remove accidental uses of `&A: Allocator`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Skip late bound regions in GATSubstCollector
#93227 liberated late bound regions when collecting GAT substs in wfcheck. It should simply skip late bound regions instead.
r? ``@compiler-errors``
Rename `impl_constness` to `constness`
The current code is a basis for `is_const_fn_raw`, and `impl_constness`
is no longer a valid name, which is previously used for determining the
constness of impls, and not items in general.
r? `@oli-obk`
add comments in `store_dead_field_or_variant`
support multiple log level
add a item ident label
fix ui tests
fix a ui test
fix a rustdoc ui test
use let chain
refactor: remove `store_dead_field_or_variant`
fix a tiny bug
once cell renamings
This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128
- Move/rename `lazy::{OnceCell, Lazy}` to `cell::{OnceCell, LazyCell}`
- Move/rename `lazy::{SyncOnceCell, SyncLazy}` to `sync::{OnceLock, LazyLock}`
(I used `Lazy...` instead of `...Lazy` as it seems to be more consistent, easier to pronounce, etc)
```@rustbot``` label +T-libs-api -T-libs
Batch proc_macro RPC for TokenStream iteration and combination operations
This is the first part of #86822, split off as requested in https://github.com/rust-lang/rust/pull/86822#pullrequestreview-1008655452. It reduces the number of RPC calls required for common operations such as iterating over and concatenating TokenStreams.
Rollup of 5 pull requests
Successful merges:
- #97803 (Impl Termination for Infallible and then make the Result impls of Termination more generic)
- #97828 (Allow configuring where artifacts are downloaded from)
- #98150 (Emscripten target: replace -g4 with -g, and -g3 with --profiling-funcs)
- #98195 (Fix rustdoc json primitive handling)
- #98205 (Remove a possible unnecessary assignment)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove a possible unnecessary assignment
The reference issue has been closed (the feature has been stabilized)
and things work fine without it, it seems.
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
Emscripten target: replace -g4 with -g, and -g3 with --profiling-funcs
Emscripten prints the following warning:
```
emcc: warning: please replace -g4 with -gsource-map [-Wdeprecated]
```
`@sbc100`
The reference issue has been closed (the feature has been stabilized)
and things work fine without fine, it seems.
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
ctfe: limit hashing of big const allocations when interning
Const allocations are only hashed for interning. However, they can be large, making the hashing expensive especially since it uses `FxHash`: it's better suited to short keys, not potentially big buffers like the actual bytes of allocation and the associated 1/8th sized `InitMask`.
We can partially hash these fields when they're large, hashing the length, and head and tail of these buffers, to
limit possible collisions while avoiding most of the hashing work.
r? `@ghost`
Rollup of 5 pull requests
Successful merges:
- #95392 (std: Stabilize feature try_reserve_2 )
- #97798 (Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown)
- #97844 (Windows: No panic if function not (yet) available)
- #98013 (Subtype FRU fields first in `type_changing_struct_update`)
- #98191 (Remove the rest of unnecessary `to_string`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Subtype FRU fields first in `type_changing_struct_update`
So this fixes a subtle bug that `type_changing_struct_update` introduced, where it'll no longer coerce the base expr correctly. I actually think this code is easier to understand now, too.
r? `@lcnr` since you reviewed the last one
Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown
This is an attempt to fix suggestions one part of which is 6 lines or more far from the first. I've noticed "the problem" (of not showing some parts of the suggestion) here: https://github.com/rust-lang/rust/pull/97759#discussion_r889689230.
I'm not sure about the implementation (this big closure is just bad and makes already complicated code even more so), but I want to at least discuss the result.
Here is an example of how this changes the output:
Before:
```text
help: consider enclosing expression in a block
|
3 ~ 'l: { match () { () => break 'l,
4 |
5 |
6 |
7 |
8 |
...
```
After:
```text
help: consider enclosing expression in a block
|
3 ~ 'l: { match () { () => break 'l,
4 |
...
31|
32~ } };
|
```
r? `@estebank`
`@rustbot` label +A-diagnostics +A-suggestion-diagnostics
`BitSet` related perf improvements
This commit makes two changes:
1. Changes `MaybeLiveLocals` to use `ChunkedBitSet`
2. Overrides the `fold` method for the iterator for `ChunkedBitSet`
I have local benchmarks verifying that each of these changes individually yield significant perf improvements to #96451 . I'm hoping this will be true outside of that context too. If that is not the case, I'll try to gate things on where they help as needed
r? `@nnethercote` who I believe was working on closely related things, cc `@tmiasko` because of the destprop pr
Move `finish` out of the `Encoder` trait.
This simplifies things, but requires making `CacheEncoder` non-generic.
(This was previously merged as commit 4 in #94732 and then was reverted
in #97905 because it caused a perf regression.)
r? `@ghost`
This is an experimental patch to try to reduce the codegen complexity of
TokenStream's FromIterator and Extend implementations for downstream
crates, by moving the core logic into a helper type. This might help
improve build performance of crates which depend on proc_macro as
iterators are used less, and the compiler may take less time to do
things like attempt specializations or other iterator optimizations.
The change intentionally sacrifices some optimization opportunities,
such as using the specializations for collecting iterators derived from
Vec::into_iter() into Vec.
This is one of the simpler potential approaches to reducing the amount
of code generated in crates depending on proc_macro, so it seems worth
trying before other more-involved changes.
This significantly reduces the cost of common interactions with TokenStream
when running with the CrossThread execution strategy, by reducing the number of
RPC calls required.
Rollup of 5 pull requests
Successful merges:
- #97377 (Do not suggest adding semicolon/changing delimiters for macros in item position that originates in macros)
- #97675 (Make `std::mem::needs_drop` accept `?Sized`)
- #98118 (Test NLL fix of bad lifetime inference for reference captured in closure.)
- #98166 (Add rustdoc-json regression test for #98009)
- #98169 (Keyword docs: Link to wikipedia article for dynamic dispatch)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Make `std::mem::needs_drop` accept `?Sized`
This change attempts to make `needs_drop` work with types like `[u8]` and `str`.
This enables code in types like `Arc<T>` that was not possible before, such as https://github.com/rust-lang/rust/pull/97676.
Compile `unicode-normalization` faster
Various optimizations and cleanups aimed at improving compilation of `unicode-normalization`, which is notable for having several very large `match`es with many char ranges.
Best reviewed one commit at a time.
r? `@oli-obk`
Big const allocations hash a large amount of data for interning:
the whole bytes buffer, and the 1/8th sized initmask, with FxHash.
This hash function is made for shorter keys.
This only hashes the length, and head and tail of these buffers, to
limit possible collisions while avoiding most of the hashing work.
Previously we only show at most 6 lines of suggestions and, if the
suggestions are more than 6 lines apart, we've just showed ... at the
end. This is probably fine, but quite confusing in my opinion.
This commit is an attempt to show ... in places where there is nothing
to suggest instead, for example:
Before:
```text
help: consider enclosing expression in a block
|
3 ~ 'l: { match () { () => break 'l,
4 |
5 |
6 |
7 |
8 |
...
```
After:
```text
help: consider enclosing expression in a block
|
3 ~ 'l: { match () { () => break 'l,
4 |
...
31|
32~ } };
|
```
Support lint expectations for `--force-warn` lints (RFC 2383)
Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope.
This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust.
This will probably conflict with https://github.com/rust-lang/rust/pull/97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix.
---
r? `@wesleywiser`
cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. 🙃
Follow-up of: https://github.com/rust-lang/rust/pull/87835
Issue: https://github.com/rust-lang/rust/issues/85549
Yeah, and that's it.
This simplifies things, but requires making `CacheEncoder` non-generic.
(This was previously merged as commit 4 in #94732 and then was reverted
in #97905 because it caused a perf regression.)
This commit removes the `a == b` early return, which isn't useful in
practice, and replaces it with one that helps matches with many ranges,
including char ranges.
The code is clearer and simpler without it. Note that the `a == b` early
return at the top of the function means the `a == b` test at the end of
the function could never succeed.
It's never executed when running the entire test suite. I think it's
because of the early return at the top of the function if `a.ty() != ty`
succeeds.
This is a performance win for `unicode-normalization`.
The commit also removes the closure, which isn't necessary. And
reformulates the comparison into a form I find easier to read.
The `MissingDoc` lint has quadratic behaviour when processing doc comments.
This is a problem for large doc comments (e.g. 1000+ lines) when
`deny(missing_code)` is enabled.
A 1000-line doc comment using `//!` comments is represented as 1000 attributes
on an item. The lint machinery iterates over each attribute with
`visit_attribute`. `MissingDoc`'s impl of that function calls
`with_lint_attrs`, which calls `enter_attrs`, which iterates over all 1000
attributes looking for a `doc(hidden)` attribute. I.e. for every attribute we
iterate over all the other attributes.
The fix is simple: don't call `with_lint_attrs` on attributes. This makes
sense: `with_lint_attrs` is intended to iterate over the attributes on a
language fragment like a statement or expression, but it doesn't need to
be called on attributes themselves.
Refactor path segment parameter error
This PR attempts to rewrite the error handling for an unexpected parenthesised type parameters to:
- Use provided data instead of re-parsing the whole span
- Add a multipart suggestion to reflect on the changes with an underline
- Remove the unnecessary "if" nesting
Fix suggestions for `&a: T` parameters
I've accidentally discovered that we have broken suggestions for `&a: T` parameters:
```rust
fn f(&mut bar: u32) {}
fn main() {
let _ = |&mut a| ();
}
```
```text
error[E0308]: mismatched types
--> ./t.rs:1:6
|
1 | fn f(&mut bar: u32) {}
| ^^^^^^^^-----
| | |
| | expected due to this
| expected `u32`, found `&mut _`
| help: did you mean `bar`: `&u32`
|
= note: expected type `u32`
found mutable reference `&mut _`
error[E0308]: mismatched types
--> ./t.rs:4:23
|
4 | let _: fn(u32) = |&mut a| ();
| ^^^^^--
| | |
| | expected due to this
| expected `u32`, found `&mut _`
| help: did you mean `a`: `&u32`
|
= note: expected type `u32`
found mutable reference `&mut _`
```
It's hard to see, but
1. The help span is overlapping with "expected" spans
2. It suggests `fn f( &u32) {}` (no `mut` and lost parameter name) and `|&u32 ()` (no closing `|` and lost parameter name)
I've tried to fix this.
r? ``@compiler-errors``
[RFC 2011] Minimal initial implementation
Tracking issue: #44838
Third step of #96496
Implementation has ~290 LOC with the bare minimum to be in a functional state. Currently only searches for binary operations to mimic what `assert_eq!` and `assert_ne!` already do.
r? `@oli-obk`
The code now accepts `Binder<OutlivesPredicate>`
instead of just `OutlivesPredicate` and thus exercises
the new, generalized `IfEqBound` codepaths. Note though
that we never *produce* Binder<OutlivesPredicate>, so we
are only testing a subset of those codepaths that excludes
actual higher-ranked outlives bounds.
STD support for the Nintendo 3DS
Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though, only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support, which will come in a follow-up PR as it requires more complicated changes.
This has been a joint effort by `@Meziu,` `@ian-h-chamberlain,` myself, and prior work by `@rust3ds` members.
### Background
The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system, with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA), the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs, since they might be considered a trade secret or under NDA.
To get around this, the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead, it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain, but in our testing, we used the following to fill in the other functions:
- [`libctru`] - provides more basic APIs, such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys).
- [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`].
- [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`].
For more details, see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR.
### Notes
We've already upstreamed changes to the [`libc`] crate to support this PR, as well as the upcoming threading PR. These changes have all been released as of 0.2.121, so we bump the crate version in this PR.
Edit: After some rebases, the version bump has already been merged so it doesn't appear in this PR.
A lot of the changes in this PR are straightforward, and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666.
The 3DS does not support user space process spawning, so these APIs are unimplemented (similar to ESP-IDF).
[`libctru`]: https://github.com/devkitPro/libctru
[`libc`]: https://github.com/rust-lang/libc
The current code is a basis for `is_const_fn_raw`, and `impl_constness`
is no longer a valid name, which is previously used for determining the
constness of impls, and not items in general.
Remove `rustc_deprecated` diagnostics
Follow-up on #95960. The diagnostics will remain until the next bootstrap, at which point people will have had six weeks to adjust.
``@rustbot`` label +A-diagnostics
r? ``@compiler-errors``
Make `ExprKind::Closure` a struct variant.
Simple refactor since we both need it to introduce additional fields in `ExprKind::Closure`.
r? ``@Aaron1011``
Remove thread-local `IGNORED_ATTRIBUTES`.
It's just a copy of the read-only global `ich::IGNORED_ATTRIBUTES`, and
can be removed without any effect.
r? `@michaelwoerister`
Rollup of 7 pull requests
Successful merges:
- #97822 (Filter out intrinsics if we have other import candidates to suggest)
- #98026 (Move some tests to more reasonable directories)
- #98067 (compiler: remove unused deps)
- #98078 (Use unchecked mul to compute slice sizes)
- #98083 (Rename rustc_serialize::opaque::Encoder as MemEncoder.)
- #98087 (Suggest adding a `#[macro_export]` to a private macro)
- #98113 (Fix misspelling of "constraint" as "contraint")
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Rename rustc_serialize::opaque::Encoder as MemEncoder.
This avoids the name clash with `rustc_serialize::Encoder` (a trait),
and allows lots qualifiers to be removed and imports to be simplified
(e.g. fewer `as` imports).
(This was previously merged as commit 5 in #94732 and then was reverted
in #97905 because of a perf regression caused by commit 4 in #94732.)
r? ```@bjorn3```
Use unchecked mul to compute slice sizes
This allows LLVM to realize that `slice.len() > 0` iff `slice.len() * size_of::<T>() > 0`, allowing a branch on the latter to be folded into the former when dropping vecs and boxed slices, in some cases.
Fixes (partially) #96497
Filter out intrinsics if we have other import candidates to suggest
Fixes#97618
Also open to just sorting these candidates to be last. Pretty easy to modify the code to do that, too.
Improve parsing errors and suggestions for bad `if` statements
1. Parses `if {}` as `if <err> {}` (block-like conditions that are missing a "then" block), and `if true && {}` as `if true && <err> {}` (unfinished binary operation), which is a more faithful recovery and leads to better typeck errors later on.
1. Points out the span of the condition if we don't see a "then" block after it, to help the user understand what is being parsed as a condition (and by elimination, what isn't).
1. Allow `if cond token else { }` to be fixed properly to `if cond { token } else { }`.
1. Fudge with the error messages a bit. This is somewhat arbitrary and I can revert my rewordings if they're useless.
----
Also this PR addresses a strange parsing regression (1.20 -> 1.21) where we chose to reject this piece of code somewhat arbitrarily, even though we should parse it fine:
```rust
fn main() {
if { if true { return } else { return }; } {}
}
```
For context, all of these other expressions parse correctly:
```rust
fn main() {
if { if true { return } else { return } } {}
if { return; } {}
if { return } {}
if { return if true { } else { }; } {}
}
```
The parser used a heuristic to determine if the "the parsed `if` condition makes sense as a condition" that did like a one-expr-deep reachability analysis. This should not be handled by the parser though.
