about summary refs log tree commit diff
path: root/src
AgeCommit message (Collapse)AuthorLines
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 #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.
2019-12-20Rollup merge of #67367 - 0dvictor:options, r=CentrilMazdak Farrokhzad-936/+957
Move command line option definitions into a dedicated file config.rs has reached the 3000 line tidy limit, this commit moves command line option definitions into a new file - options.rs, and leaves the rest of configuration infrastructure in config.rs.
2019-12-20Rollup merge of #67328 - rkruppe:simplify-u128-f32-cast, r=matthewjasperMazdak Farrokhzad-36/+7
Remove now-redundant range check on u128 -> f32 casts This code was added to avoid UB in LLVM 6 and earlier, but we no longer support those LLVM versions. Since https://reviews.llvm.org/D47807 (released in LLVM 7), uitofp does exactly what we need. Closes #51872
2019-12-20Rollup merge of #67285 - ohadravid:indicate-origin-of-where-type-parameter, ↵Mazdak Farrokhzad-41/+97
r=estebank Indicate origin of where type parameter for uninferred types Based on #65951 (which is not merge yet), fixes #67277. This PR improves a little the diagnostic for code like: ``` async fn foo() { bar().await; } async fn bar<T>() -> () {} ``` by showing: ``` error[E0698]: type inside `async fn` body must be known in this context --> unresolved_type_param.rs:9:5 | 9 | bar().await; | ^^^ cannot infer type for type parameter `T` declared on the function `bar` | ... ``` (The ``` declared on the function `bar` ``` part is new) A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`. r? @estebank
2019-12-20Rollup merge of #67219 - jsgf:command-argv0-debug, r=joshtriplettMazdak Farrokhzad-2/+30
Fix up Command Debug output when arg0 is specified. PR https://github.com/rust-lang/rust/pull/66512 added the ability to set argv[0] on Command. As a side effect, it changed the Debug output to print both the program and argv[0], which in practice results in stuttery output (`"echo" "echo" "foo"`). This PR reverts the behaviour to the the old one, so that the command is only printed once - unless arg0 has been set. In that case it emits `"[command]" "arg0" "arg1" ...`.
2019-12-20Rollup merge of #67127 - estebank:disambiguate-suggestion, r=varkorMazdak Farrokhzad-82/+274
Use structured suggestion for disambiguating method calls Fix #65635.
2019-12-20Rollup merge of #66755 - mark-i-m:const-vec-new, r=ecstatic-morseMazdak Farrokhzad-18/+4
Remove a const-if-hack in RawVec r? @ecstatic-morse cc @Centril
2019-12-20Move command line option definitions into a dedicated fileVictor Ding-936/+957
config.rs has reached the 3000 line tidy limit, this commit moves command line option definitions into a new file - options.rs, and leaves the rest of configuration infrastructure in config.rs.
2019-12-19Remove newline from commit in toolstateMark Rousskov-1/+1
2019-12-20Remove `SOCK_CLOEXEC` dummy variable on platforms that don't use it.Markus Reiter-18/+9
2019-12-19Rollup merge of #67436 - NieDzejkob:todo-stabilization-fix, r=alexcrichtonMark Rousskov-2/+2
Correct the todo! stabilization version None
2019-12-19Rollup merge of #67432 - Mark-Simulacrum:fix-toolstate, r=CentrilMark Rousskov-1/+1
Fix toolstate history format We were inserting *before* the existing newline, so we should prepend it not append it to our inserted string.
2019-12-19Rollup merge of #67421 - LeSeulArtichaut:patch-1, r=CentrilMark Rousskov-1/+1
Fix internal documentation typo r? @Centril
2019-12-19Rollup merge of #67351 - Mark-Simulacrum:always-channel, r=pietroalbiniMark Rousskov-4/+9
Set release channel on non-dist builders Toolstate publication only runs if the channel is "nightly" and previously the toolstate builders did not know that the channel was nightly (since they are not dist builders). A look through bootstrap seems to indicate that nothing should directly depend on the channel being set to `-dev` on the test builders, though this may cause some problems with UI tests (if for some reason they're dumping the channel into stderr), but we cannot find evidence of such so hopefully this is fine. r? @pietroalbini
2019-12-19Rollup merge of #67281 - llogiq:nonoverlapping-insert, r=alexcrichtonMark Rousskov-0/+40
add string.insert benchmarks This adds benchmarks for `String::insert` and `String::insert_str`
2019-12-19Rollup merge of #67253 - elichai:2019-12-fmt, r=Dylan-DPCMark Rousskov-44/+76
Add more delegations to the fmt docs and add doctests HI, this is a continuation to #67021 I replaced the `Debug` example with one that use the `Debug*` helpers so that padding etc will work too. I also added asserts for the doctests as @RalfJung asked :) The only thing I left with the `write!` macro is the `Display` example as I didn't know if there's a better way to do that. r? @QuietMisdreavus
2019-12-19Fix toolstate history formatMark Rousskov-1/+1
We were inserting *before* the existing newline, so we should prepend it not append it to our inserted string.
2019-12-19Correct the todo! stabilization versionJakub Kądziołka-2/+2
2019-12-19Fix documentation typoLeSeulArtichaut-1/+1
2019-12-19Rollup merge of #67406 - ohadravid:suggest-assoc-type, r=estebankMazdak Farrokhzad-32/+73
Suggest associated type when the specified one cannot be found Fixes #67386, so code like this: ``` use std::ops::Deref; fn homura<T: Deref<Trget = i32>>(_: T) {} fn main() {} ``` results in: ``` error[E0220]: associated type `Trget` not found for `std::ops::Deref` --> type-binding.rs:6:20 | 6 | fn homura<T: Deref<Trget = i32>>(_: T) {} | ^^^^^^^^^^^ help: there is an associated type with a similar name: `Target` error: aborting due to previous error ``` (The `help` is new) I used an `all_candidates: impl Fn() -> Iterator<...>` instead of `collect`ing to avoid the cost of allocating the Vec when no errors are found, at the expense of a little added complexity. r? @estebank
2019-12-19Rollup merge of #67394 - matthew-healy:update-libsyntax-ptr-docs, r=Dylan-DPCMazdak Farrokhzad-7/+2
Remove outdated references to @T from comments Closes #67341. This removes all references to `@T` from the comment in libsyntax/ptr.rs.
2019-12-19Rollup merge of #67389 - reitermarkus:dummy-variable, r=shepmasterMazdak Farrokhzad-12/+6
Remove `SO_NOSIGPIPE` dummy variable on platforms that don't use it.
2019-12-19Rollup merge of #67382 - nnethercote:rm-unnecessary-ATTR-constants, ↵Mazdak Farrokhzad-29/+17
r=michaelwoerister Remove some unnecessary `ATTR_*` constants. r? @michaelwoerister
2019-12-19Rollup merge of #67321 - lzutao:htons, r=dtolnayMazdak Farrokhzad-22/+11
make htons const fn This may partially help #67315.
2019-12-19Rollup merge of #67286 - cuviper:configure-llvm, r=Dylan-DPCMazdak Farrokhzad-2/+2
Fix the configure.py TOML field for a couple LLVM options The actual fields in `config.toml.example` have dashes, not underscores.
2019-12-19Rollup merge of #67270 - alexcrichton:write-more-line-writer, r=sfacklerMazdak Farrokhzad-1/+171
std: Implement `LineWriter::write_vectored` This commit implements the `write_vectored` method of the `LineWriter` type. First discovered in bytecodealliance/wasmtime#629 the `write_vectored` method of `Stdout` bottoms out here but only ends up writing the first buffer due to the default implementation of `write_vectored`. Like `BufWriter`, however, `LineWriter` can have a non-default implementation of `write_vectored` which tries to preserve the vectored-ness as much as possible. Namely we can have a vectored write for everything before the newline and everything after the newline if all the stars align well. Also like `BufWriter`, though, special care is taken to ensure that whenever bytes are written we're sure to signal success since that represents a "commit" of writing bytes.
2019-12-19Rollup merge of #67189 - LeSeulArtichaut:binop-wording, r=estebankMazdak Farrokhzad-112/+153
Unify binop wording Closes #60497 r? @estebank
2019-12-18Set release channel on non-dist buildersMark Rousskov-4/+9
Toolstate publication only runs if the channel is "nightly" and previously the toolstate builders did not know that the channel was nightly (since they are not dist builders). A look through bootstrap seems to indicate that nothing should directly depend on the channel being set to `-dev` on the test builders, though this may cause some problems with UI tests (if for some reason they're dumping the channel into stderr), but we cannot find evidence of such so hopefully this is fine.
2019-12-18no need to bootstrapMark Mansi-9/+2
2019-12-18add fixmeMark Mansi-0/+1
2019-12-18fix importMark Mansi-1/+1
2019-12-18use usize::MAX instead of !0Mark Mansi-1/+1
2019-12-18remove a bit more hackeryMark Mansi-41/+9
2019-12-18Remove a const-if-hack in RawVecMark Mansi-8/+32
2019-12-18Fix comment orderingMatthew Jasper-4/+4