Aaron Hill [Mon, 3 Feb 2020 23:34:36 +0000 (18:34 -0500)]
Record proc macro harness order for use during metadata deserialization
Fixes #68690
When we generate the proc macro harness, we now explicitly recorder the
order in which we generate entries. We then use this ordering data to
deserialize the correct proc-macro-data from the crate metadata.
bors [Sat, 15 Feb 2020 10:20:05 +0000 (10:20 +0000)]
Auto merge of #69182 - Dylan-DPC:rollup-ifsa9fx, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #64069 (Added From<Vec<NonZeroU8>> for CString)
- #66721 (implement LowerExp and UpperExp for integers)
- #69106 (Fix std::fs::copy on WASI target)
- #69154 (Avoid calling `fn_sig` on closures)
- #69166 (Check `has_typeck_tables` before calling `typeck_tables_of`)
- #69180 (Suggest a comma if a struct initializer field fails to parse)
Dylan DPC [Sat, 15 Feb 2020 08:45:49 +0000 (09:45 +0100)]
Rollup merge of #69180 - Aaron1011:feature/comma-struct-init, r=petrochenkov
Suggest a comma if a struct initializer field fails to parse
Currently, we emit a "try adding a comma" suggestion if a comma is
missing in a struct definition. However, we emit no such suggestion if a
comma is missing in a struct initializer.
This commit adds a "try adding a comma" suggestion when we don't find a
comma during the parsing of a struct initializer field.
The change to `src/test/ui/parser/removed-syntax-with-1.stderr` isn't
great, but I don't see a good way of avoiding it.
Dylan DPC [Sat, 15 Feb 2020 08:45:45 +0000 (09:45 +0100)]
Rollup merge of #69106 - RReverser:wasi-fs-copy, r=KodrAus
Fix std::fs::copy on WASI target
Previously `std::fs::copy` on wasm32-wasi would reuse code from the `sys_common` module and would successfully copy contents of the file just to fail right before closing it.
This was happening because `sys_common::copy` tries to copy permissions of the file, but permissions are not a thing in WASI (at least yet) and `set_permissions` is implemented as an unconditional runtime error.
This change instead adds a custom working implementation of `std::fs::copy` (like Rust already has on some other targets) that doesn't try to call `set_permissions` and is essentially a thin wrapper around `std::io::copy`.
This implementation is heavily based on the preexisting `macro_rules! impl_Display` in the same file. I don't like the liberal use of unsafe in that macro and would like to modify it so `unsafe` is only present where necessary. What is Rust's policy on doing such modifications?
Also, I couldn't figure out where to put tests, can I have some help with that?
Dylan DPC [Sat, 15 Feb 2020 08:45:38 +0000 (09:45 +0100)]
Rollup merge of #64069 - danielhenrymantilla:feature/cstring_from_vec_of_nonzerou8, r=KodrAus
Added From<Vec<NonZeroU8>> for CString
Added a `From<Vec<NonZeroU8>>` `impl` for `CString`
# Rationale
- `CString::from_vec_unchecked` is a subtle function, that makes `unsafe` code harder to audit when the generated `Vec`'s creation is non-trivial. This `impl` allows to write safer `unsafe` code thanks to the very explicit semantics of the `Vec<NonZeroU8>` type.
- One such situation is when trying to `.read()` a `CString`, see issue #59229.
- this lead to a PR: #59314, that was closed for being too specific / narrow (it only targetted being able to `.read()` a `CString`, when this pattern could have been generalized).
- the issue suggested another route, based on `From<Vec<NonZeroU8>>`, which is indeed a less general and more concise code pattern.
- quoting @shnatsel:
- > For me the main thing about making this safe is simplifying auditing - people have spent like an hour looking at just this one unsafe block in libflate because it's not clear what exactly is unchecked, so you have to look it up when auditing anyway. This has distracted us from much more serious memory safety issues the library had.
Having this trivial impl in stdlib would turn this into safe code with compiler more or less guaranteeing that it's fine, and save anyone auditing the code a whole lot of time.
Aaron Hill [Sat, 15 Feb 2020 03:28:13 +0000 (22:28 -0500)]
Suggest a comma if a struct initializer field fails to parse
Currently, we emit a "try adding a comma" suggestion if a comma is
missing in a struct definition. However, we emit no such suggestion if a
comma is missing in a struct initializer.
This commit adds a "try adding a comma" suggestion when we don't find a
comma during the parsing of a struct initializer field.
The change to `src/test/ui/parser/removed-syntax-with-1.stderr` isn't
great, but I don't see a good way of avoiding it.
bors [Sat, 15 Feb 2020 02:24:04 +0000 (02:24 +0000)]
Auto merge of #67681 - matthewjasper:infer-regions-in-borrowck, r=nikomatsakis
Infer regions for opaque types in borrowck
This is a step towards the goal of typeck not doing region inference.
The commits up to `Arena allocate the result of mir_borrowck` are various bug fixes and prerequisites.
The remaining commits move opaque type inference to borrow checking.
Matthew Jasper [Sat, 11 Jan 2020 14:12:39 +0000 (14:12 +0000)]
Improve opaque type lifetime errors
* Use better span for member constraint errors
* Avoid a bad suggestion
* Don't report member constraint errors if we have other universal
region errors.
Yuki Okushi [Fri, 14 Feb 2020 22:17:50 +0000 (07:17 +0900)]
Rollup merge of #69128 - Centril:fix-69103, r=davidtwco
Fix extra subslice lowering
We are currently ICEing on e.g.
```rust
fn main() {
let [.., b @ ..] = [1, 2];
b;
}
```
This happens because `b @ ..` registers a binding such that `b;` is OK, but then we forget to lower that binding in `rustc_ast_lowering`.
Yuki Okushi [Fri, 14 Feb 2020 22:17:49 +0000 (07:17 +0900)]
Rollup merge of #69051 - Centril:st-fixes, r=eddyb
simplify_try: address some of eddyb's comments
Addresses only https://github.com/rust-lang/rust/pull/66282#discussion_r376730986 and https://github.com/rust-lang/rust/pull/66282#discussion_r376730824.
Yuki Okushi [Fri, 14 Feb 2020 22:17:47 +0000 (07:17 +0900)]
Rollup merge of #68856 - Centril:or-pat-ref-pat, r=matthewjasper
typeck: clarify def_bm adjustments & add tests for or-patterns
Clarify the adjustment algorithm for the expected type / default binding-modes when type checking patterns with more documentation and tweaks that make the algorithm more independent of the pattern forms.
Also resolve the FIXME noted for or-patterns by deciding that the current implementation is correct, noting the rationale and adding tests for the current implementation.
Yuki Okushi [Fri, 14 Feb 2020 22:17:45 +0000 (07:17 +0900)]
Rollup merge of #68475 - Aaron1011:fix/forest-caching, r=nikomatsakis
Use a `ParamEnvAnd<Predicate>` for caching in `ObligationForest`
Previously, we used a plain `Predicate` to cache results (e.g. successes
and failures) in ObligationForest. However, fulfillment depends on the
precise `ParamEnv` used, so this is unsound in general.
This commit changes the impl of `ForestObligation` for
`PendingPredicateObligation` to use `ParamEnvAnd<Predicate>` instead of
`Predicate` for the associated type. The associated type and method are
renamed from 'predicate' to 'cache_key' to reflect the fact that type is
no longer just a predicate.
bors [Fri, 14 Feb 2020 19:59:05 +0000 (19:59 +0000)]
Auto merge of #69115 - ehuss:update-books, r=Dylan-DPC
Update books.
This required some changes in how the books are tested due to some changes in rust-lang/book. It uses new syntax that is not compatible with bare `rustdoc --test`. This changes it so that it uses rustbook to run the tests, which is essentially the same as `mdbook test`.
## reference
7 commits in 11e893fc1357bc688418ddf1087c2b7aa25d154d..64239df6d173562b9deb4f012e4c3e6e960c4754
2020-01-18 21:24:08 +0100 to 2020-02-10 19:05:13 +0100
- Update for nested receivers. (rust-lang-nursery/reference#724)
- clarify note re. leading `::` in 2018 (rust-lang-nursery/reference#752)
- Update macro-ambiguity.md (rust-lang-nursery/reference#754)
- typo fix: add missing `by` (rust-lang-nursery/reference#753)
- fix `TypeParamBounds` link on trait objects (rust-lang-nursery/reference#749)
- reorganize docs on references (rust-lang-nursery/reference#745)
- add MacroRepOp usage for ? (rust-lang-nursery/reference#744)
## book
49 commits in 87dd6843678575f8dda962f239d14ef4be14b352..6fb3705e5230311b096d47f7e2c91f9ce24393d0
2020-01-20 15:20:40 -0500 to 2020-02-12 13:48:57 -0500
- Fix nomicon links. (rust-lang/book#2253)
- Update to Rust 1.41.0 (rust-lang/book#2244)
- Listing 19-6: use ptr.add instead of ptr.offset (rust-lang/book#2201)
- Remove unneeded mutable reference
- Clarify deref coercion explanation
- Fix typo in link to 1.30 book
- Acknowledge Murphy's Law
- Clarify that buffer overread is UB in C
- Change from "must" to "idiomatic" about comments
- Fancy quotes
- Make HashMap types match previous example; add fwd ref to ch 13
- Tweak wording to array clarification
- Merge remote-tracking branch 'origin/pr/2236'
- Update all our crates (rust-lang/book#2235)
- Reword git caveat
- Merge remote-tracking branch 'origin/pr/2234'
- Merge remote-tracking branch 'origin/pr/2230'
- println! is a macro (rust-lang/book#2224)
- Update a translated version link (rust-lang/book#2221)
- move `Macro invocation` from section on tuple to section on mac… (rust-lang/book#2206)
- Do not limit `Self` usage in trait implementation (rust-lang/book#2197)
- Merge remote-tracking branch 'origin/pr/2191'
- Fix wrapping
- Merge remote-tracking branch 'origin/pr/2187'
- Updated appendix 07 to reflect deprecation of rustup install (rust-lang/book#2181)
- Make links to the Nomicon consistent
- Merge remote-tracking branch 'origin/pr/2180'
- Merge remote-tracking branch 'origin/pr/2175'
- Merge remote-tracking branch 'origin/pr/2171'
- Merge remote-tracking branch 'origin/pr/2170'
- Clarify and make consistent the explanation of unions
- Merge remote-tracking branch 'origin/pr/2166'
- Handle dev or test in the Finished output line
- Link to macros by example rather than macros (rust-lang/book#2164)
- Merge remote-tracking branch 'origin/pr/2147'
- Fix parens (rust-lang/book#2132)
- Clarify type inference with closures requires calling the closures
- Update link to French translation (rust-lang/book#2119)
- Merge remote-tracking branch 'origin/pr/2108'
- Add an explicit cross reference to data type
- Merge remote-tracking branch 'origin/pr/2105'
- ch15-02-deref: Improve explanation on immut-to-mut (rust-lang/book#2030)
- Remove unnecessary quotes
- Make markdown link identifier match
- Remove extra newline
- Merge remote-tracking branch 'origin/pr/2004'
- Extract code and output; script formatting and updating them (rust-lang/book#2231)
- Switch "Finally" to "Next" to reflect new chapters having been… (rust-lang/book#2098)
- ch19-06 added curly braces to macro output (rust-lang/book#2050)
Dylan DPC [Thu, 13 Feb 2020 20:28:09 +0000 (21:28 +0100)]
Rollup merge of #69126 - RalfJung:exact-div, r=oli-obk
miri: fix exact_div
Turns out `exact_div` was relying on the broken behavior of `Rem` for `int_min % -1` that was fixed in https://github.com/rust-lang/rust/pull/69002. This PR fixes `exact_div`.
Inside rustc, `exact_div` is only used in a single place where the divisor is always positive (in `ptr_offset_from`), so we cannot test the fix in rustc. The Miri test suite covers this through the `exact_div` intrinsic, though (and it is how I found out).
One step to https://github.com/rust-lang/rust/issues/69117 (then we also need to address build failures introduced by https://github.com/rust-lang/rust/pull/68969)
Dylan DPC [Thu, 13 Feb 2020 20:27:58 +0000 (21:27 +0100)]
Rollup merge of #68728 - Centril:towards-fn-merge, r=petrochenkov
parse: merge `fn` syntax + cleanup item parsing
Here we continue the work in https://github.com/rust-lang/rust/pull/67131 in particular to merge the grammars of `fn` items in various positions.
A list of *language level* changes (as sanctioned by the language team in https://github.com/rust-lang/rust/issues/65041#issuecomment-538105286 and https://github.com/rust-lang/rust/pull/67131):
- `self` parameters are now *syntactically* allowed as the first parameter irrespective of item context (and in function pointers). Instead, semantic validation (`ast_validation`) is used.
- Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead.
- Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns.
- `const extern fn` feature gating is now done post-expansion such that we do not have conditional compatibilities of function qualifiers *in parsing*.
That is, all item contexts now *syntactically* allow `const async unsafe extern "C" fn` and use semantic restrictions to rule out combinations previously prevented syntactically. The semantic restrictions include in particular:
- `fn`s in `extern { ... }` can have no qualifiers.
- `const` and `async` cannot be combined.
- To fuse the list-of-items parsing in the 4 contexts that items are allowed, we now must permit inner attributes (`#![attr]`) inside `trait Foo { ... }` definitions. That is, we now allow e.g. `trait Foo { #![attr] }`. This was probably an oversight due to not using a uniform parsing mechanism, which we now do have (`fn parse_item_list`). The semantic support (including e.g. for linting) falls out directly from the attributes infrastructure. To ensure this, we include a test for lints.
Put together, these grammar changes allow us to substantially reduce the complexity of item parsing and its grammar. There are however some other non-language improvements that allow the compression to take place.
A list of *compiler-internal* changes (in particular noting the parser-external data-structure changes):
- We use `enum AllowPlus/RecoverQPath/AllowCVariadic { Yes, No }` in `parser/ty.rs` instead of passing around 3 different `bool`s. I felt this was necessary as it was becoming mentally taxing to track which-is-which.
- `fn visit_trait_item` and `fn visit_impl_item` are merged into `fn visit_assoc_item` which now is passed an `AssocCtxt` to check which one it is.
This is then taken advantage of in tweaking the various semantic restrictions as well as in pretty printing.
- In `ItemKind::Fn`, we change `P<Block>` to `Option<P<Block>>`.
- In `ForeignItemKind::Fn`, we change `P<FnDecl>` to `FnSig` and `P<Block>` to `Option<P<Block>>`.
- We change `ast::{Unsafety, Spanned<Constness>}>` into `enum ast::{Unsafe, Const} { Yes(Span), No }` respectively. This change in formulation allow us to exclude `Span` in the case of `No`, which facilitates parsing. Moreover, we also add a `Span` to `IsAsync` which is renamed to `Async`. The new `Span`s in `Unsafety` and `Async` are then taken advantage of for better diagnostics. A reason this change was made is to have a more uniform and clear naming scheme.
The HIR keeps the structures in AST (with those definitions moved into HIR) for now to avoid regressing perf.
- Various cleanups, bug fixes, and diagnostics improvements are made along the way. It is probably best to understand those via the diffs.
I would recommend reviewing this commit-by-commit with whitespace changes hidden.
bors [Thu, 13 Feb 2020 12:53:43 +0000 (12:53 +0000)]
Auto merge of #68969 - RalfJung:dont-panic, r=oli-obk
remove Panic variant from InterpError
The interpreter engine itself does not raise `Panic` errors any more, so remove them from the error enum. Instead, const-prop and const-eval have to do their own handling of panics.
I used the opportunity to refactor the const-eval error handling a bit to use the `MachineStop` variant.
Also, in const-prop I could do some cleanup as now, no more lints are being reported in `use_ecx`. However, I am quite puzzled by why exactly the linting there works the way it does -- the code can certainly be cleaned up more, but I don't know enough of the intent to do that. I left some questions for the most confusing parts, but for now behavior should be unchanged by this PR (so, all that weirdness I am asking about is pre-existing and merely maintained here). Cc @wesleywiser