about summary refs log tree commit diff
path: root/src
AgeCommit message (Collapse)AuthorLines
2019-12-21Drop petgraph dependency from bootstrapMark Rousskov-47/+1
It was essentially unused, likely leftover from a previous refactoring iteration.
2019-12-21Auto merge of #66994 - Centril:stmt-polish, r=estebankbors-1187/+1764
refactor expr & stmt parsing + improve recovery Summary of important changes (best read commit-by-commit, ignoring whitespace changes): - `AttrVec` is introduces as an alias for `ThinVec<Attribute>` - `parse_expr_bottom` and `parse_stmt` are thoroughly refactored. - Extract diagnostics logic for `vec![...]` in a pattern context. - Recovery is added for `do catch { ... }` - Recovery is added for `'label: non_block_expr` - Recovery is added for `var $local`, `auto $local`, and `mut $local`. Fixes #65257. - Recovery is added for `e1 and e2` and `e1 or e2`. - ~~`macro_legacy_warnings` is turned into an error (has been a warning for 3 years!)~~ - Fixes #63396 by forward-porting #64105 which now works thanks to added recovery. - `ui-fulldeps/ast_stmt_expr_attr.rs` is turned into UI and pretty tests. - Recovery is fixed for `#[attr] if expr {}` r? @estebank
2019-12-21Auto merge of #67464 - Centril:rollup-j3mkl1m, r=Centrilbors-1828/+2090
Rollup of 6 pull requests Successful merges: - #67130 (Const prop should finish propagation into user defined variables) - #67163 (Split up ptr/mod.rs in libcore...) - #67314 (Don't suppress move errors for union fields) - #67392 (Fix unresolved type span inside async object) - #67404 (Separate region inference logic from error handling better) - #67428 (`is_binding_pat`: use explicit match & include or-pats in grammar) Failed merges: r? @ghost
2019-12-20tweak var/auto/mut recoveryMazdak Farrokhzad-31/+39
2019-12-20use .span_suggestion_short for &&Mazdak Farrokhzad-10/+10
2019-12-20ast_stmt_expr_attr -> pretty & ui testsMazdak Farrokhzad-311/+692
2019-12-20fix bug in parse_tuple_parens_expr + related refactoringMazdak Farrokhzad-68/+49
2019-12-20recover `#[attr] if expr {}`Mazdak Farrokhzad-8/+54
2019-12-20recover on 'mut', 'var', 'auto'Mazdak Farrokhzad-3/+120
2019-12-20introduce 'type AttrVec'Mazdak Farrokhzad-176/+136
2019-12-20simplify parse_bottom_expr moreMazdak Farrokhzad-78/+76
2019-12-20use mk_expr_err moreMazdak Farrokhzad-1/+1
2019-12-20extract parse_lit_expr and simplifyMazdak Farrokhzad-79/+64
2019-12-20extract parse_break_exprMazdak Farrokhzad-10/+16
2019-12-20refactor parse_incorrect_await_syntaxMazdak Farrokhzad-14/+24
2019-12-20extract parse_{expr_opt, return_expr, yield_expr}Mazdak Farrokhzad-31/+34
2019-12-20recover on 'do catch { .. }'Mazdak Farrokhzad-21/+47
2019-12-20pass attr as param in new methodsMazdak Farrokhzad-10/+11
2019-12-20add recovery to parse_labeled_exprMazdak Farrokhzad-3/+27
2019-12-20extract parse_labeled_exprMazdak Farrokhzad-25/+29
2019-12-20extract parse_path_start_exprMazdak Farrokhzad-27/+30
2019-12-20extract parse_array_or_repeat_exprMazdak Farrokhzad-41/+43
2019-12-20extract parse_tuple_parens_exprMazdak Farrokhzad-34/+31
2019-12-20Clean up `parse_bottom_expr`A C-60/+39
2019-12-20Add a UI test for correct parsingA C-0/+32
2019-12-20parse_bottom_expr: use else ifMazdak Farrokhzad-14/+13
2019-12-20implement recovery in check_assoc_opMazdak Farrokhzad-92/+100
2019-12-20extract should_continue_as_assoc_exprMazdak Farrokhzad-45/+55
2019-12-20extract: error_block_no_opening_braceMazdak Farrokhzad-59/+65
2019-12-20parser: extract error_outer_attrsMazdak Farrokhzad-14/+14
2019-12-20parse_stmt_without_recovery: readability!Mazdak Farrokhzad-54/+54
2019-12-20parse_stmt_mac: add a commentMazdak Farrokhzad-0/+1
2019-12-20extract suggest_slice_patMazdak Farrokhzad-21/+25
2019-12-20parser: early return for item stmtMazdak Farrokhzad-40/+39
2019-12-20inline parse_stmt_ into parse_stmtMazdak Farrokhzad-6/+2
2019-12-20extract parse_sttmt_macMazdak Farrokhzad-63/+73
2019-12-20reduce repetition in stmt parsingMazdak Farrokhzad-56/+37
2019-12-20Rollup merge of #67428 - Centril:ibp-explicit-match, r=matthewjasperMazdak Farrokhzad-1/+9
`is_binding_pat`: use explicit match & include or-pats in grammar r? @matthewjasper @nikomatsakis
2019-12-20Rollup merge of #67404 - mark-i-m:split-1, r=matthewjasperMazdak Farrokhzad-88/+96
Separate region inference logic from error handling better Split out from #67241 r? @matthewjasper
2019-12-20Rollup merge of #67392 - csmoe:async-typeinfo, r=estebankMazdak Farrokhzad-7/+24
Fix unresolved type span inside async object Closes #65180 r? @estebank It's hard to create a minimal repro for that issue, [decided](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/meeting.202019.2E12.2E17/near/183675659) to give up finding mcve. cc [previous take](https://github.com/rust-lang/rust/pull/65668)
2019-12-20Rollup merge of #67314 - matthewjasper:union-move-errors, r=nikomatsakisMazdak Farrokhzad-9/+79
Don't suppress move errors for union fields closes #66500
2019-12-20Rollup merge of #67163 - TheSamsa:split-up-ptr-mod, r=Mark-SimulacrumMazdak Farrokhzad-1701/+1695
Split up ptr/mod.rs in libcore... ...one with implementation detail for const ptr and the other with mut ptr I am not sure if the "stable since 1.0.0" flags are the correct choice for the two additional mods. Also, is it necessary for them to be "pub"? If so, there should be a good description for them. Closes #66891
2019-12-20Rollup merge of #67130 - wesleywiser:const_prop_into_locals, r=oli-obkMazdak Farrokhzad-22/+187
Const prop should finish propagation into user defined variables Fixes #66638 ~~Temporarily rebased on top of #67015 to get those fixes.~~ r? @oli-obk
2019-12-20Auto merge of #67020 - pnkfelix:issue-59535-accumulate-past-lto-imports, r=mwbors-10/+250
save LTO import info and check it when trying to reuse build products Fix #59535 Previous runs of LTO optimization on the previous incremental build can import larger portions of the dependence graph into a codegen unit than the current compilation run is choosing to import. We need to take that into account when we choose to reuse PostLTO-optimization object files from previous compiler invocations. This PR accomplishes that by serializing the LTO import information on each incremental build. We load up the previous LTO import data as well as the current LTO import data. Then as we decide whether to reuse previous PostLTO objects or redo LTO optimization, we check whether the LTO import data matches. After we finish with this decision process for every object, we write the LTO import data back to disk. ---- What is the scenario where comparing against past LTO import information is necessary? I've tried to capture it in the comments in the regression test, but here's yet another attempt from me to summarize the situation: 1. Consider a call-graph like `[A] -> [B -> D] <- [C]` (where the letters are functions and the modules are enclosed in `[]`) 2. In our specific instance, the earlier compilations were inlining the call to`B` into `A`; thus `A` ended up with a external reference to the symbol `D` in its object code, to be resolved at subsequent link time. The LTO import information provided by LLVM for those runs reflected that information: it explicitly says during those runs, `B` definition and `D` declaration were imported into `[A]`. 3. The change between incremental builds was that the call `D <- C` was removed. 4. That change, coupled with other decisions within `rustc`, made the compiler decide to make `D` an internal symbol (since it was no longer accessed from other codegen units, this makes sense locally). And then the definition of `D` was inlined into `B` and `D` itself was eliminated entirely. 5. The current LTO import information reported that `B` alone is imported into `[A]` for the *current compilation*. So when the Rust compiler surveyed the dependence graph, it determined that nothing `[A]` imports changed since the last build (and `[A]` itself has not changed either), so it chooses to reuse the object code generated during the previous compilation. 6. But that previous object code has an unresolved reference to `D`, and that causes a link time failure! ---- The interesting thing is that its quite hard to actually observe the above scenario arising, which is probably why no one has noticed this bug in the year or so since incremental LTO support landed (PR #53673). I've literally spent days trying to observe the bug on my local machine, but haven't managed to find the magic combination of factors to get LLVM and `rustc` to do just the right set of the inlining and `internal`-reclassification choices that cause this particular problem to arise. ---- Also, I have tried to be careful about injecting new bugs with this PR. Specifically, I was/am worried that we could get into a scenario where overwriting the current LTO import data with past LTO import data would cause us to "forget" a current import. ~~To guard against this, the PR as currently written always asserts, at overwrite time, that the past LTO import-set is a *superset* of the current LTO import-set. This way, the overwriting process should always be safe to run.~~ * The previous note was written based on the first version of this PR. It has since been revised to use a simpler strategy, where we never attempt to merge the past LTO import information into the current one. We just *compare* them, and act accordingly. * Also, as you can see from the comments on the PR itself, I was quite right to be worried about forgetting past imports; that scenario was observable via a trivial transformation of the regression test I had devised.
2019-12-20Better commentWho? Me?!-1/+1
Co-Authored-By: matthewjasper <mjjasper1@gmail.com>
2019-12-20Rollup merge of #67363 - alexcrichton:wasm-import-modules, r=eddybMazdak Farrokhzad-4/+189
Fix handling of wasm import modules and names The WebAssembly targets of rustc have weird issues around name mangling and import the same name from different modules. This all largely stems from the fact that we're using literal symbol names in LLVM IR to represent what a function is called when it's imported, and we're not using the wasm-specific `wasm-import-name` attribute. This in turn leads to two issues: * If, in the same codegen unit, the same FFI symbol is referenced twice then rustc, when translating to LLVM IR, will only reference one symbol from the first wasm module referenced. * There's also a bug in LLD [1] where even if two codegen units reference different modules, having the same symbol names means that LLD coalesces the symbols and only refers to one wasm module. Put another way, all our imported wasm symbols from the environment are keyed off their LLVM IR symbol name, which has lots of collisions today. This commit fixes the issue by implementing two changes: 1. All wasm symbols with `#[link(wasm_import_module = "...")]` are mangled by default in LLVM IR. This means they're all given unique names. 2. Symbols then use the `wasm-import-name` attribute to ensure that the WebAssembly file uses the correct import name. When put together this should ensure we don't trip over the LLD bug [1] and we also codegen IR correctly always referencing the right symbols with the right import module/name pairs. Closes #50021 Closes #56309 Closes #63562 [1]: https://bugs.llvm.org/show_bug.cgi?id=44316
2019-12-20Rollup merge of #67354 - VirrageS:blame-wrong-line, r=estebankMazdak Farrokhzad-33/+86
Fix pointing at arg when cause is outside of call Follow up after: #66933 Closes: #66923 r? @estebank
2019-12-20Rollup merge of #67131 - Centril:item-merge, r=petrochenkovMazdak Farrokhzad-849/+1279
Merge `TraitItem` & `ImplItem into `AssocItem` In this PR we: - Merge `{Trait,Impl}Item{Kind?}` into `AssocItem{Kind?}` as discussed in https://github.com/rust-lang/rust/issues/65041#issuecomment-538105286. - This is done by using the cover grammar of both forms. - In particular, it requires that we syntactically allow (under `#[cfg(FALSE)]`): - `default`ness on `trait` items, - `impl` items without a body / definition (`const`, `type`, and `fn`), - and associated `type`s in `impl`s with bounds, e.g., `type Foo: Ord;`. - The syntactic restrictions are replaced by semantic ones in `ast_validation`. - Move syntactic restrictions around C-variadic parameters from the parser into `ast_validation`: - `fn`s in all contexts now syntactically allow `...`, - `...` can occur anywhere in the list syntactically (`fn foo(..., x: usize) {}`), - and `...` can be the sole parameter (`fn foo(...) {}`. r? @petrochenkov
2019-12-20Rollup merge of #64588 - matthewjasper:mir-address-of, r=oli-obkMazdak Farrokhzad-516/+1159
Add a raw "address of" operator * Parse and feature gate `&raw [const | mut] expr` (feature gate name is `raw_address_of`) * Add `mir::Rvalue::AddressOf` * Use the new `Rvalue` for: * the new syntax * reference to pointer casts * drop shims for slices and arrays * Stop using `mir::Rvalue::Cast` with a reference as the operand * Correctly evaluate `mir::Rvalue::{Ref, AddressOf}` in constant propagation cc @Centril @RalfJung @oli-obk @eddyb cc #64490
2019-12-20Rollup merge of #67442 - reitermarkus:dummy-variable, r=kennytmMazdak Farrokhzad-18/+9
Remove `SOCK_CLOEXEC` dummy variable on platforms that don't use it.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-09-29 09:31:18 +0000