Fix recursive nonterminal expansion during pretty-print/reparse check
Makes progress towards #43081
In PR #73084, we started recursively expanded nonterminals during the
pretty-print/reparse check, allowing them to be properly compared
against the reparsed tokenstream.
Unfortunately, the recursive logic in that PR only handles the case
where a nonterminal appears inside a `TokenTree::Delimited`. If a
nonterminal appears directly in the expanded tokens of another
nonterminal, the inner nonterminal will not be expanded.
This PR fixes the recursive expansion of nonterminals, ensuring that
they are expanded wherever they occur.
Rollup of 12 pull requests
Successful merges:
- #77037 (more tiny clippy cleanups)
- #77233 (BTreeMap: keep an eye out on the size of the main components)
- #77280 (Ensure that all LLVM components requested by tests are available on CI)
- #77284 (library: Forward compiler-builtins "mem" feature)
- #77296 (liveness: Use Option::None to represent absent live nodes)
- #77322 (Add unstable book docs for `-Zunsound-mir-opts`)
- #77328 (Use `rtassert!` instead of `assert!` from the child process after fork() in std::sys::unix::process::Command::spawn())
- #77331 (Add test for async/await combined with const-generics.)
- #77338 (Fix typo in alloc vec comment)
- #77340 (Alloc vec use imported path)
- #77345 (Add test for issue #74761)
- #77348 (Update books)
Failed merges:
r? `@ghost`
Add support for cmse_nonsecure_entry attribute
This pull request adds the `cmse_nonsecure_entry` attribute under an unstable feature.
I was not sure if it was fine for me to send directly the pull-request or if I should submit a RFC first. I was told on Zulip that it was fine to do so but please close it if I need first submit a RFC or follow another process instead.
The `cmse_nonsecure_entry` attribute is a LLVM attribute that will be available in LLVM 11. I plan to rebase on the [upgrade PR](https://github.com/rust-lang/rust/pull/73526) once merged to make this one compile.
This attribute modifies code generation of the function as explained [here](https://developer.arm.com/documentation/ecm0359818/latest/) to make it work with the TrustZone-M hardware feature. This feature is only available on `thumbv8m` targets so I created an error for that if one tries to use this attribute for another target.
I added this attribute in Rust as any other LLVM attribute are added but since this one is target-dependent I am not sure if it was the best thing to do. Please indicate me if you think of other ways, like isolating target-dependent attributes together.
----------------
Tracking issue: https://github.com/rust-lang/rust/issues/75835
This patch adds support for the LLVM cmse_nonsecure_entry attribute.
This is a target-dependent attribute that only has sense for the
thumbv8m Rust targets.
You can find more information about this attribute here:
https://developer.arm.com/documentation/ecm0359818/latest/
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
Secure entry functions do not support if arguments are passed on the
stack. An "unsupported" diagnostic will be emitted by LLVM if that is
the case.
This commits adds support in Rust for that diagnostic so that an error
will be output if that is the case!
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
SipHasher128 implements short_write in an endian-independent way, yet
its write_xxx Hasher trait methods undo this endian-independence by byte
swapping the integer inputs on big-endian hardware. StableHasher then
adds endian-independence back by also byte-swapping on big-endian
hardware prior to invoking SipHasher128.
This double swap may have the appearance of being a no-op, but is in
fact by design. In particular, we really do want SipHasher128 to be
platform-dependent, in order to be consistent with the libstd SipHasher.
Try to clarify this intent. Also, add and update a couple of unit tests.
This helper function was meant to reduce code duplication between
const-checking pre- and post-drop-elaboration. Most of the functionality
is only relevant for the pre-drop-elaboration pass.
Liveness refactoring continued
* Move body_owner field from IrMaps to Liveness (the only user of the field).
* Use upvars instead of FnKind to check for closures (avoids FnKind, will be useful when checking all bodies, not just fns).
* Use visit_param to add variables corresponding to params.
* Store upvars_mentioned inside Liveness struct.
* Inline visitor implementation for IrMaps, avoiding unnecessary indirection.
* Test interaction with automatically_derived attribute (not covered by any of existing tests).
No functional changes intended.
This commit improves the "try using the enum's variant" suggestion:
- Variants in suggestions would not result in more errors (e.g. use
of a struct variant is only suggested if the suggestion can
trivially construct that variant). Therefore, suggestions are only
emitted for variants that have no fields (since the suggestion
can't know what value fields would have).
- Suggestions include the syntax for constructing the variant. If a
struct or tuple variant is suggested, then it is constructed in the
suggestion - unless in pattern-matching or when arguments are already
provided.
- A help message is added which mentions the variants which are no
longer suggested.
Signed-off-by: David Wood <david@davidtw.co>
