Auto merge of #87580 - ChrisDenton:win-arg-parse-2008, r=m-ou-se
Update Windows Argument Parsing
Fixes #44650
The Windows command line is passed to applications [as a single string](https://docs.microsoft.com/en-us/archive/blogs/larryosterman/the-windows-command-line-is-just-a-string) which the application then parses to get a list of arguments. The standard rules (as used by C/C++) for parsing the command line have slightly changed over the years, most recently in 2008 which added new escaping rules.
This PR implements the new rules as [described on MSDN](https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=msvc-160#parsing-c-command-line-arguments) and [further detailed here](https://daviddeley.com/autohotkey/parameters/parameters.htm#WIN). It has been tested against the behaviour of C++ by calling a C++ program that outputs its raw command line and the contents of `argv`. See [my repo](https://github.com/ChrisDenton/winarg/tree/std) if anyone wants to reproduce my work.
For an overview of how this PR changes argument parsing behavior and why we feel it is warranted see https://github.com/rust-lang/rust/pull/87580#issuecomment-893833893.
For some examples see: https://github.com/rust-lang/rust/pull/87580#issuecomment-894299249
Auto merge of #83342 - Count-Count:win-console-incomplete-utf8, r=m-ou-se
Allow writing of incomplete UTF-8 sequences to the Windows console via stdout/stderr
# Problem
Writes of just an incomplete UTF-8 byte sequence (e.g. `b"\xC3"` or `b"\xF0\x9F"`) to stdout/stderr with a Windows console attached error with `io::ErrorKind::InvalidData, "Windows stdio in console mode does not support writing non-UTF-8 byte sequences"` even though further writes could complete the codepoint. This is currently a rare occurence since the [linewritershim](https://github.com/rust-lang/rust/blob/2c56ea38b045624dc8b42ec948fc169eaff1206a/library/std/src/io/buffered/linewritershim.rs) implementation flushes complete lines immediately and buffers up to 1024 bytes for incomplete lines. It can still happen as described in #83258.
The problem will become more pronounced once the developer can switch stdout/stderr from line-buffered to block-buffered or immediate when the changes in the "Switchable buffering for Stdout" pull request (#78515) get merged.
# Patch description
If there is at least one valid UTF-8 codepoint all valid UTF-8 is passed through to the extracted `write_valid_utf8_to_console()` fn. The new code only comes into play if `write()` is being passed a short byte slice comprising an incomplete UTF-8 codepoint. In this case up to three bytes are buffered in the `IncompleteUtf8` struct associated with `Stdout` / `Stderr`. The bytes are accepted one at a time. As soon as an error can be detected `io::ErrorKind::InvalidData, "Windows stdio in console mode does not support writing non-UTF-8 byte sequences"` is returned. Once a complete UTF-8 codepoint is received it is passed to the `write_valid_utf8_to_console()` and the buffer length is set to zero.
Calling `flush()` will neither error nor write anything if an incomplete codepoint is present in the buffer.
# Tests
Currently there are no Windows-specific tests for console writing code at all. Writing (regression) tests for this problem is a bit challenging since unit tests and UI tests don't run in a console and suddenly popping up another console window might be surprising to developers running the testsuite and it might not work at all in CI builds. To just test the new functionality in unit tests the code would need to be refactored. Some guidance on how to proceed would be appreciated.
# Public API changes
* `std::str::verifications::utf8_char_width()` would be exposed as `std::str::utf8_char_width()` behind the "str_internals" feature gate.
# Related issues
* Fixes #83258.
* PR #78515 will exacerbate the problem.
# Open questions
* Add tests?
* Squash into one commit with better commit message?
Auto merge of #88522 - camelid:box-paren-output, r=jyn514
rustdoc: Box `GenericArgs::Parenthesized.output`
Split out from #88379.
This reduces the size of `GenericArgs` from 104 bytes to 56 bytes,
essentially reducing it by half.
`GenericArgs` is one of the fields of `PathSegment`, so this should
reduce the amount of memory allocated for `PathSegment`s in the cases
where the generics are not for a `Fn`, `FnMut`, or `FnOnce` trait.
Auto merge of #88563 - ehuss:update-cargo-books, r=ehuss
Update cargo, books
## nomicon
2 commits in 0c7e5bd1428e7838252bb57b7f0fbfda4ec82f02..fe6227eb3c8533200c52dffa42ef1b6f2f02c40e
2021-08-04 10:18:22 -0700 to 2021-08-31 05:42:38 +0900
- update lifetime-elision to show what elided code under `rust_2018_idi… (rust-lang/nomicon#306)
- Change code for `into_iter` on the `RawVec` section for consistency/soundness (rust-lang/nomicon#302)
## cargo
8 commits in f559c109cc79fe413a8535fb620a5a58b3823d94..18751dd3f238d94d384a7fe967abfac06cbfe0b9
2021-08-26 22:54:55 +0000 to 2021-09-01 14:26:00 +0000
- print the full destination path when no track duplicates (rust-lang/cargo#9850)
- Stabilize 2021 edition (rust-lang/cargo#9800)
- Stabilize patch-in-config (and prefer config over manifest) (rust-lang/cargo#9839)
- Adding the cargo doc --examples subcommand (rust-lang/cargo#9808)
- Make library created with `cargo new` clippy happy (rust-lang/cargo#9796)
- Swap out some outdated repo urls in documentation (rust-lang/cargo#9862)
- Change `cargo fix --edition` to only fix edition lints. (rust-lang/cargo#9846)
- Show desc of well known subcommands (fmt, clippy) in cargo --list (rust-lang/cargo#9848)
7 commits in cf0e151b7925a40f13fbc6573c6f97d5f94c7c17..95f1acf9a39d6f402f654e917e2c1dfdb779c5fc
2021-08-22 11:47:02 -0300 to 2021-08-31 12:38:30 -0500
- Add link to `Span`
- Add rustc-source to suggested rust-analyzer config (rust-lang/rustc-dev-guide#1189)
- Fix typo, clarify backtick wording, and use inline code
- Trailing date comments in a line inside of a paragraph caused beginning of a new paragraph. (rust-lang/rustc-dev-guide#1196)
- Fix warning "Renderer command uses a path relative to the renderer output directory ..." (rust-lang/rustc-dev-guide#1194)
- Fix a code block containing ```rust
- date-check: Recognize capitalized 'Date' as well
Auto merge of #88269 - prconrad:doctest-persist-binaries, r=jyn514
Doctest persist full binaries when persisting
Tested by adding an extra debug to echo the whole compiler line. Trimmed significantly:
Persisted but not running -> full compile so we get binaries (new behavior).
```
$ rustdoc -Zunstable-options --test --persist-doctests doctests --no-run --extern t=libt.rlib t.rs
Not running and not persisting -> save time and only run metadata.
```
RUSTDOC_LOG=rustdoc=debug,std::test=debug rustdoc -Zunstable-options --no-run --test --extern t=libt.rlib t.rs
Auto merge of #88556 - m-ou-se:rollup-q636wyd, r=m-ou-se
Rollup of 9 pull requests
Successful merges:
- #86376 (Emit specific warning to clarify that `#[no_mangle]` should not be applied on foreign statics or functions)
- #88040 (BTree: remove Ord bound from new)
- #88053 (Fix the flock fallback implementation)
- #88350 (add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC)
- #88410 (Remove bolding on associated constants)
- #88525 (fix(rustc_typeck): produce better errors for dyn auto trait)
- #88542 (Use the return value of readdir_r() instead of errno)
- #88548 (Stabilize `Iterator::intersperse()`)
- #88551 (Stabilize `UnsafeCell::raw_get()`)
Mara Bos [Wed, 1 Sep 2021 07:23:31 +0000 (09:23 +0200)]
Rollup merge of #88551 - inquisitivecrystal:unsafe_cell_raw_get, r=m-ou-se
Stabilize `UnsafeCell::raw_get()`
This PR stabilizes the associated function `UnsafeCell::raw_get()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/66358#issuecomment-899095068). While there was some discussion about the naming after the close of the FCP, it looks like people have agreed on this name. Still, it would probably be best if a `libs-api` member had a look at this and stated whether more discussion is needed.
While I was at it, I added some tests for `UnsafeCell`, because there were barely any.
Mara Bos [Wed, 1 Sep 2021 07:23:30 +0000 (09:23 +0200)]
Rollup merge of #88548 - inquisitivecrystal:intersperse, r=m-ou-se
Stabilize `Iterator::intersperse()`
This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616).
Mara Bos [Wed, 1 Sep 2021 07:23:23 +0000 (09:23 +0200)]
Rollup merge of #88040 - nbdd0121:btreemap, r=m-ou-se
BTree: remove Ord bound from new
`K: Ord` bound is unnecessary on `BTree{Map,Set}::new` and their `Default` impl. No elements exist so there are nothing to compare anyway, so I don't think "future proof" would be a blocker here. This is analogous to `HashMap::new` not having a `K: Eq + Hash` bound.
#79245 originally does this and for some reason drops the change to `new` and `Default`. I can see why changes to other methods like `entry` or `symmetric_difference` need to be careful but I couldn't find out any reason not to do it on `new`.
Removing the bound also makes the stabilisation of `const fn new` not depending on const trait bounds.
Mara Bos [Wed, 1 Sep 2021 07:23:22 +0000 (09:23 +0200)]
Rollup merge of #86376 - asquared31415:extern-no-mangle-84204, r=Mark-Simulacrum
Emit specific warning to clarify that `#[no_mangle]` should not be applied on foreign statics or functions
Foreign statics and foreign functions should not have `#[no_mangle]` applied, as it does nothing to the name and has some extra hidden behavior that is normally unwanted. There was an existing warning for this, but it says the attribute is only allowed on "statics or functions", which to the user can be confusing.
This PR adds a specific version of the unused `#[no_mangle]` warning that explains that the target is a *foreign* static or function and that they do not need the attribute.
Auto merge of #88272 - willcrichton:mutable-sparse-matrix, r=ecstatic-morse
Add bit removal methods to SparseBitMatrix and factor *BitSet relational methods into more extensible trait
I need the ability to clear the bits out of a row from `SparseBitMatrix`. Currently, all the mutating methods only allow insertion of bits, and there is no way to get access to the underlying data.
One approach is simply to make `ensure_row` public, since it grants `&mut` access to the underlying `HybridBitSet`. This PR adds the `pub` modifier. However, presumably this method was private for a reason, so I'm open to other designs. I would prefer general mutable access to the rows, because that way I can add many mutating operations (`clear`, `intersect`, etc.) without filing a PR each time :-)
Noah Lev [Mon, 23 Aug 2021 04:35:01 +0000 (21:35 -0700)]
Box `GenericArgs::Parenthesized.output`
This reduces the size of `GenericArgs` from 104 bytes to 56 bytes,
essentially reducing it by half.
`GenericArgs` is one of the fields of `PathSegment`, so this should
reduce the amount of memory allocated for `PathSegment`s in the cases
where the generics are not for a `Fn`, `FnMut`, or `FnOnce` trait.
I also added `static_assert_size!`s to `GenericArgs` and `PathSegment`
to ensure they don't increase in size unexpectedly.
Auto merge of #87688 - camsteffen:let-else, r=cjgillot
Introduce `let...else`
Tracking issue: #87335
The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..`, but I decided against this because, when a "mismatched type" error is found in typeck, there is no way to trace where in the HIR the expected type originated, AFAICT. In order to pass down this information, I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType`, but I left that as a future enhancement. For now, I simply assert that the block is `!` with a custom `ObligationCauseCode`, and I think this is clear enough, at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect.
Overall, I believe this PR is feature-complete with regard to the RFC.
bors [Tue, 31 Aug 2021 22:15:26 +0000 (22:15 +0000)]
Auto merge of #88533 - oli-obk:tait_🧊, r=spastorino
Concrete regions can show up in mir borrowck if the originated from there
We used to not encounter them here, because we took regions from typeck's opaque type resolution by renumbering them. We don't do that anymore. Instead mir borrock does all the logic, and it can handle concrete regions just fine, as long as it created them itself.
Mara Bos [Tue, 31 Aug 2021 15:54:57 +0000 (17:54 +0200)]
Rollup merge of #88445 - inquisitivecrystal:ast-lowering, r=cjgillot
Clean up the lowering of AST items
This PR simplifies and improves `rustc_ast_lowering::item` in various minor ways. The reasons for the changes should mostly be self evident, though I'm happy to specifically explain anything if needed.
These changes used to be part of #88019, but I removed them after it was pointed out that some of my other changes to `rustc_ast_lowering` were unnecessary. It felt like a bad idea to clean up code which I didn't even need to touch anymore.
Mara Bos [Tue, 31 Aug 2021 15:54:52 +0000 (17:54 +0200)]
Rollup merge of #85017 - clarfonthey:carrying_widening, r=m-ou-se
Add carrying_add, borrowing_sub, widening_mul, carrying_mul methods to integers
This comes in part from my own attempts to make (crude) big integer implementations, and also due to the stalled discussion in [RFC 2417](https://github.com/rust-lang/rfcs/pull/2417). My understanding is that changes like these are best offered directly as code and then an RFC can be opened if there needs to be more discussion before stabilisation. Since all of these methods are unstable from the start, I figured I might as well offer them now.
I tried looking into intrinsics, messed around with a few different implementations, and ultimately concluded that these are "good enough" implementations for now to at least put up some code and maybe start bikeshedding on a proper API for these.
For the `carrying_add` and `borrowing_sub`, I tried looking into potential architecture-specific code and realised that even using the LLVM intrinsics for `addcarry` and `subborrow` on x86 specifically, I was getting exactly the same assembly as the naive implementation using `overflowing_add` and `overflowing_sub`, although the LLVM IR did differ because of the architecture-specific code. Longer-term I think that they would be best suited to specific intrinsics as that would make optimisations easier (instructions like add-carry tend to use implicit flags, and thus can only be optimised if they're done one-after-another, and thus it would make the most sense to have compact intrinsics that can be merged together easily).
For `widening_mul` and `carrying_mul`, for now at least, I simply cast to the larger type and perform arithmetic that way, since we currently have no intrinsic that would work better for 128-bit integers. In the future, I also think that some form of intrinsic would work best to cover that case, but for now at least, I think that they're "good enough" for now.
The main reasoning for offering these directly to the standard library even though they're relatively niche optimisations is to help ensure that the code generated for them is optimal. Plus, these operations alone aren't enough to create big integer implementations, although they could help simplify the code required to do so and make it a bit more accessible for the average implementor.
That said, I 100% understand if any or all of these methods are not desired simply because of how niche they are. Up to you. 🤷🏻
In https://github.com/rust-lang/rust/issues/88475, a situation was found where `[T; N].into_iter()` becomes *ambiguous* in the new edition. This is different than the case where `(&[T; N]).into_iter()` resolves differently, which was the only case handled by the `array_into_iter` lint. This is almost identical to the new-traits-in-the-prelude problem. Effectively, due to the array-into-iter hack disappearing in Rust 2021, we effectively added `IntoIterator` to the 'prelude' in Rust 2021 specifically for arrays.
This modifies the prelude collisions lint to detect that case and emit a `array_into_iter` lint in that case.
bors [Tue, 31 Aug 2021 03:34:22 +0000 (03:34 +0000)]
Auto merge of #88414 - Aaron1011:guess-foreign-head-span, r=estebank
Don't use `guess_head_span` in `predicates_of` for foreign span
Previously, the result of `predicates_of` for a foreign trait
would depend on the *current* state of the corresponding source
file in the foreign crate. This could lead to ICEs during incremental
compilation, since the on-disk contents of the upstream source file
could potentially change without the upstream crate being recompiled.
Additionally, this ensure that that the metadata we produce for a crate
only depends on its *compiled* upstream dependencies (e.g an rlib or
rmeta file), *not* the current on-disk state of the upstream crate
source files.
bors [Mon, 30 Aug 2021 22:21:01 +0000 (22:21 +0000)]
Auto merge of #88369 - lcnr:cec-rename, r=oli-obk
update const generics feature gates
**tl;dr: split const generics into three features: `adt_const_params`, `const_generics_defaults` and `generic_const_exprs`**
continuing the work of `@BoxyUwU` in #88324, this PR
- renames `feature(const_evaluatable_checked)` to `feature(generic_const_exprs)` which now doesn't need any other feature gate to work. Previously `feature(const_evaluatable_checked)` was only useful in combination with `feature(const_generics)`.
- completely removes `feature(lazy_normalization_consts)`. This feature only supplied the parents generics to anonymous constants, which is pretty useless as generic anon consts are only allowed with `feature(generic_const_exprs)` anyways.
- moves the ability to use additional const param types from `feature(const_generics)` into `feature(adt_const_params)`. As `feature(const_generics)` is now mostly useless without `feature(generic_const_exprs)` we also remove that feature flag.
- updates tests, removing duplicates and unnecessary revisions in some cases and also deletes all unused `*.stderr` files.
I not also remove the ordering restriction for const and type parameters if any of the three const generics features is active.
This ordering restriction feels like the only "real" use of the current `feature(const_generics)` right now so this change isn't a perfect solution, but as I intend to stabilize the ordering - and `feature(const_generics_defaults)` - in the very near future, I think this is acceptable for now.
---
cc `@rust-lang/project-const-generics` about the new feature names and this change in general.
I don't think we need any external approval for this change but I do intend to publish an update to the const generics tracking issue the day this PR lands, so I don't want this merged yet.
Apologies to whoever ends up reviewing this PR :sweat_smile: :heart:
projects / rust.git / log