trans: Fix missing closure env drop-glue in trans-item collector.
FnOnce adapters automatically generated by the compiler introduce a call to drop the closure environment. The collector didn't pick up on that because this drop call does not show up in MIR. That could lead to an assertion being triggered if the drop-glue for the environment wasn't instantiated via something else.
Fixes#38810
cc @arielb1
r? @eddyb or @nikomatsakis
rustc: use -Xlinker when specifying an rpath with ',' in it
The `-Wl` option splits its parameters on commas, so if rustc specifies
`-Wl,-rpath,<path>` when `<path>` contains commas, the path gets split up
and the linker gets a partial path and spurious extra parameters.
Gcc/clang support the more verbose `-Xlinker` option to pass options to the linker directly, so use it for comma-containing paths.
Fixes issue #38795.
Reduce the size of static data in std_unicode::tables
`BoolTrie` works well for sets of code points spread out through most of Unicode’s range, but is uses a lot of space for sets with few, mostly low, code points.
This switches a few of its instances to a similar but simpler trie data structure.
CC @raphlinus, who wrote the original `BoolTrie`.
## Before
`size_of::<BoolTrie>()` is 1552, which is added to `table.r3.len() * 8 + t.r5.len() + t.r6.len() * 8`:
* `Cc_table`: 1632
* `White_Space_table`: 1656
* `Pattern_White_Space_table`: 1640
* Total: 4928 bytes
## After
`size_of::<SmallBoolTrie>()` is 32, which is added to `t.r1.len() + t.r2.len() * 8`:
* `Cc_table`: 51
* `White_Space_table`: 273
* `Pattern_White_Space_table`: 193
* Total: 517 bytes
## Difference
Every Rust program with `std` statically linked should be about 4 KB smaller.
Add PeekMut::pop
A fairly common workflow is to put a bunch of stuff into a binary heap
and then mutate the top value until its empty. This both makes that a
bit more convenient (no need to save a boolean off and pop after to
avoid borrowck issues), and a bit more efficient since you only shift
once.
r? @alexcrichton
cc @rust-lang/libs
Implement placement-in protocol for `Vec`
Follow-up of #32366 per comment at https://github.com/rust-lang/rust/issues/30172#issuecomment-268099009, updating to latest rust, leaving @apasel422 as author and putting myself as committer.
I've removed the implementation of `push` in terms of place to make this PR more conservative.
E0088/E0090 fix
This fixes an issue reported by @eddyb (https://github.com/rust-lang/rust/pull/36208#issuecomment-2707092230) where the check for "too few lifetime parameters" was removed in one of the error message PRs.
I also removed the span shrinking from E0088, as early bound lifetimes give you a confusing underline in some cases.
r=eddyb
std: Don't pass overlapped handles to processes
This commit fixes a mistake introduced in #31618 where overlapped handles were
leaked to child processes on Windows. On Windows once a handle is in overlapped
mode it should always have I/O executed with an instance of `OVERLAPPED`. Most
child processes, however, are not prepared to have their stdio handles in
overlapped mode as they don't use `OVERLAPPED` on reads/writes to the handle.
Now we haven't had any odd behavior in Rust up to this point, and the original
bug was introduced almost a year ago. I believe this is because it turns out
that if you *don't* pass an `OVERLAPPED` then the system will [supply one for
you][link]. In this case everything will go awry if you concurrently operate on
the handle. In Rust, however, the stdio handles are always locked, and there's
no way to not use them unlocked in libstd. Due to that change we've always had
synchronized access to these handles, which means that Rust programs typically
"just work".
Conversely, though, this commit fixes the test case included, which exhibits
behavior that other programs Rust spawns may attempt to execute. Namely, the
stdio handles may be concurrently used and having them in overlapped mode wreaks
havoc.
[link]: https://blogs.msdn.microsoft.com/oldnewthing/20121012-00/?p=6343Closes#38811
fix help for the --print option
Since 8285ab5c99, which was merged in with #38061, the help for the
--print option is missing the surrounding [ ] around the possible
options.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Deprecate TcpListener::set_only_v6
This was supposed to have been removed in #33124 but snuck through :(
Should the docs be removed?
I left the accessor undeprecated since it should actually work, though that method doesn't exist on other networking types.
r? @alexcrichton
cc @rust-lang/libs
fix promotion of MIR terminators
promotion of MIR terminators used to try to promote the destination it
is trying to promote, leading to stack overflow.
Also clean up the code in `promote_temp` a bit to make it more understandable.
Fixes#37991.
cc @nikomatsakis
r? @eddyb
Dont check stability for items that are not pub to universe.
Dont check stability for items that are not pub to universe.
In other words, skip it for private and even `pub(restricted)` items, because stability checks are only relevant to things visible in other crates.
Fix#38412.
resolve: don't `unused_qualifications`-check global paths
We started `unused_qualifications`-checking global paths in #38014, causing #38682.
Fixes#38682.
r? @nrc
Properly ban the negation of unsigned integers in type-checking.
Lint-time banning of unsigned negation appears to be vestigial from a time it was feature-gated.
But now it always errors and we do have the ability to deref the checking of e.g. `-0`, through the trait obligation fulfillment context, which will only succeed/error when the `0` gets inferred to a specific type.
The two removed tests are the main reason for finally cleaning this up, they need changing all the time when refactoring the HIR-based `rustc_const_eval` and/or `rustc_passes::consts`, as warnings pile up.
Some i128 tests
* Add some FFI tests for i128 on architectures where we have sort of working "C" FFI support. On all other architectures we ignore the test.
* enhance the u128 overflow tests
Additional cleanup to rustc_trans
Removes `BlockAndBuilder`, `FunctionContext`, and `MaybeSizedValue`.
`LvalueRef` is used instead of `MaybeSizedValue`, which has the added benefit of making functions operating on `Lvalue`s be able to take just that (since it encodes the type with an `LvalueTy`, which can carry discriminant information) instead of a `MaybeSizedValue` and a discriminant.
r? @eddyb
rustbuild: Quickly `dist` cross-host compilers
This commit optimizes the compile time for creating tarballs of cross-host
compilers and as a proof of concept adds two to the standard Travis matrix. Much
of this commit is further refactoring and refining of the `step.rs` definitions
along with the interpretation of `--target` and `--host` flags. This has gotten
confusing enough that I've also added a small test suite to
`src/bootstrap/step.rs` to ensure what we're doing works and doesn't regress.
After this commit when you execute:
./x.py dist --host $MY_HOST --target $MY_HOST
the build system will compile two compilers. The first is for the build platform
and the second is for the host platform. This second compiler is then packaged
up and placed into `build/dist` and is ready to go. With a fully cached LLVM and
docker image I was able to create a cross-host compiler in around 20 minutes
locally.
Eventually we plan to add a whole litany of cross-host entries to the Travis
matrix, but for now we're just adding a few before we eat up all the extra
capacity.
cc #38531
Document custom derive.
These are some bare-bones documentation for custom derive, needed
to stabilize "macros 1.1",
https://github.com/rust-lang/rust/issues/35900
The book chapter is based off of a blog post by @cbreeden,
https://cbreeden.github.io/Macros11/
Normally, we have a policy of not mentioning external crates in
documentation. However, given that syn/quote are basically neccesary
for properly using macros 1.1, I feel that not including them here
would make the documentation very bad. So the rules should be bent
in this instance.
So far, this PR includes only docs; @alexcrichton said in https://github.com/rust-lang/rust/issues/35900 that he'd be okay with landing them before stabilization; I don't mind either way.
This commit fixes a mistake introduced in #31618 where overlapped handles were
leaked to child processes on Windows. On Windows once a handle is in overlapped
mode it should always have I/O executed with an instance of `OVERLAPPED`. Most
child processes, however, are not prepared to have their stdio handles in
overlapped mode as they don't use `OVERLAPPED` on reads/writes to the handle.
Now we haven't had any odd behavior in Rust up to this point, and the original
bug was introduced almost a year ago. I believe this is because it turns out
that if you *don't* pass an `OVERLAPPED` then the system will [supply one for
you][link]. In this case everything will go awry if you concurrently operate on
the handle. In Rust, however, the stdio handles are always locked, and there's
no way to not use them unlocked in libstd. Due to that change we've always had
synchronized access to these handles, which means that Rust programs typically
"just work".
Conversely, though, this commit fixes the test case included, which exhibits
behavior that other programs Rust spawns may attempt to execute. Namely, the
stdio handles may be concurrently used and having them in overlapped mode wreaks
havoc.
[link]: https://blogs.msdn.microsoft.com/oldnewthing/20121012-00/?p=6343Closes#38811
These are some bare-bones documentation for custom derive, needed
to stabilize "macros 1.1",
https://github.com/rust-lang/rust/issues/35900
The book chapter is based off of a blog post by @cbreeden,
https://cbreeden.github.io/Macros11/
Normally, we have a policy of not mentioning external crates in
documentation. However, given that syn/quote are basically neccesary
for properly using macros 1.1, I feel that not including them here
would make the documentation very bad. So the rules should be bent
in this instance.
rustc: Stabilize the `proc_macro` feature
This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the
compiler to stabilize the "Macros 1.1" feature of the language. Many more
details can be found on the tracking issue, #35900.
Closes#35900
This commit optimizes the compile time for creating tarballs of cross-host
compilers and as a proof of concept adds two to the standard Travis matrix. Much
of this commit is further refactoring and refining of the `step.rs` definitions
along with the interpretation of `--target` and `--host` flags. This has gotten
confusing enough that I've also added a small test suite to
`src/bootstrap/step.rs` to ensure what we're doing works and doesn't regress.
After this commit when you execute:
./x.py dist --host $MY_HOST --target $MY_HOST
the build system will compile two compilers. The first is for the build platform
and the second is for the host platform. This second compiler is then packaged
up and placed into `build/dist` and is ready to go. With a fully cached LLVM and
docker image I was able to create a cross-host compiler in around 20 minutes
locally.
Eventually we plan to add a whole litany of cross-host entries to the Travis
matrix, but for now we're just adding a few before we eat up all the extra
capacity.
cc #38531
