Both `parse_tuple_struct_body` and `parse_item_struct` handled the case
of unit like struct. The redundancy is removed,
`parse_tuple_struct_body` now handles only real tuple structs.
r? @steveklabnik
##### About the `struct` section specifically:
I wasn't sure how you'd feel about the first instance since it was originally capitalized, happy to change it back if you think that's better.
Also, I left 'tuple struct' as is since together it isn't a keyword. The first instance currently has single quotes but the others have nothing. I think that feels right.
##### Generally:
I'm working through the book now and I'm happy to keep updating this branch with any formatting tweaks or updates I find if that's easier for you guys, otherwise I'll just create smaller PRs as I go. Just let me know.
Because 'doc' is a directory, when running `make doc`, you'll see
this:
make: Nothing to be done for `doc'.
By adding a target for `doc` to build `docs`, both work.
Fixes#14705
Because 'doc' is a directory, when running `make doc`, you'll see
this:
make: Nothing to be done for `doc'.
By adding a target for `doc` to build `docs`, both work.
Fixes#14705
r? @nikomatsakis
Trying to land this first stab, which basically just duplicates the AST. Will file issues for the various things I've got in mind to improve.
Running TLS destructors for a MSVC Windows binary requires the linker doesn't
elide the `_tls_used` or `__tls_used` symbols (depending on the architecture).
This is currently achieved via a `#[link_args]` hack but this only works for
dynamically linked binaries because the link arguments aren't propagated to
statically linked binaries.
This commit alters the strategy to instead emit a volatile load from those
symbols so LLVM can't elide it, forcing the reference to the symbol to stay
alive as long as the callback function stays alive (which we've made sure of
with the `#[linkage]` attribute).
Closes#28111
Running TLS destructors for a MSVC Windows binary requires the linker doesn't
elide the `_tls_used` or `__tls_used` symbols (depending on the architecture).
This is currently achieved via a `#[link_args]` hack but this only works for
dynamically linked binaries because the link arguments aren't propagated to
statically linked binaries.
This commit alters the strategy to instead emit a volatile load from those
symbols so LLVM can't elide it, forcing the reference to the symbol to stay
alive as long as the callback function stays alive (which we've made sure of
with the `#[linkage]` attribute).
Closes#28111
This changes a lot of `.to_string()` to `.to_owned()`, removes a few redundant closures, and changes some `match`es to `if let`s.
I'm currently in the process of trying out clippy and acting on its suggestions. I started with compiletest, because we use it to test clippy, too. If this finds positive reception, I may continue refactoring other parts of the rust codebase.
This is a [breaking-change] for syntax extension authors. The fix is to use MultiModifier or MultiDecorator, which have the same functionality but are more flexible. Users of syntax extensions are unaffected.
I believe everything that doesn't take a constant integer up to SSE4.2
should now be correct (I don't have any reason to believe that those
that do take constant integers are wrong; they're just more complicated
and I just haven't tested them in detail).
(Also, takes out two unused code paths from trans.)
I believe everything that doesn't take a constant integer up to SSE4.2
should now be correct (I don't have any reason to believe that those
that do take constant integers are wrong; they're just more complicated
and I just haven't tested them in detail).
This is a [breaking-change] for syntax extension authors. The fix is to use MultiModifier or MultiDecorator, which have the same functionality but are more flexible. Users of syntax extensions are unaffected.
