bors [Fri, 26 Jun 2020 14:08:46 +0000 (14:08 +0000)]
Auto merge of #73513 - oli-obk:const_binop_overflow, r=estebank
Show the values and computation that would overflow a const evaluation or propagation
Fixes #71134
In contrast to the example in the issue it doesn't use individual spans for each operand. The effort required to implement that is quite high compared to the little (if at all) benefit it would bring to diagnostics.
cc @shepmaster
The way this is implemented it is also fairly easy to do the same for overflow panics at runtime, but that should be done in a separate PR since it may have runtime performance implications.
bors [Fri, 26 Jun 2020 10:11:43 +0000 (10:11 +0000)]
Auto merge of #73756 - Manishearth:rollup-aehswb2, r=Manishearth
Rollup of 13 pull requests
Successful merges:
- #72620 (Omit DW_AT_linkage_name when it is the same as DW_AT_name)
- #72967 (Don't move cursor in search box when using arrows to navigate results)
- #73102 (proc_macro: Stop flattening groups with dummy spans)
- #73297 (Support configurable deny-warnings for all in-tree crates.)
- #73507 (Cleanup MinGW LLVM linkage workaround)
- #73588 (Fix handling of reserved registers for ARM inline asm)
- #73597 (Record span of `const` kw in GenericParamKind)
- #73629 (Make AssocOp Copy)
- #73681 (Update Chalk to 0.14)
- #73707 (Fix links in `SliceIndex` documentation)
- #73719 (emitter: column width defaults to 140)
- #73729 (disable collectionbenches for android)
- #73748 (Add code block to code in documentation of `List::rebase_onto`)
Rollup merge of #73719 - davidtwco:issue-72509-emitter-column-width, r=estebank
emitter: column width defaults to 140
Fixes #72509.
This PR modifies the column width computation in the emitter when `termize::dimensions` returns `None` so that it uses the default value of 140 (which is used in UI testing currently) instead of `usize::MAX` which just ends up causing overflows in later computations.
I also tried changing the computations which used `column_width` with their saturating equivalent, but the output appeared the same - so I decided to go with this approach because I feel like it's less likely to accidentally re-introduce an ICE like this in future (e.g. adding a non-saturating operation on `column_width` in future).
I haven't added a test because I couldn't come up with a MCVE. I stumbled upon this running rustc-perf with the `piston-image` benchmark (running in tmux; it only happened with stage two builds only; and only when running through Cargo, not rustc directly with the same flags). In addition, given the nature of the issue, I don't know that we *could* write a UI test for this. Open to suggestions here though.
Rollup merge of #73707 - LeSeulArtichaut:patch-3, r=kennytm
Fix links in `SliceIndex` documentation
See [this doc](https://doc.rust-lang.org/nightly/std/slice/trait.SliceIndex.html#tymethod.get_unchecked) whose links aren't active because of this missing newline.
Rollup merge of #73681 - jackh726:chalk-0.14, r=nikomatsakis
Update Chalk to 0.14
Not a ton here. Notable changes:
- Update to `0.14.0`
- New dependency on `tracing`, in `librustc_traits` only
- `FnAbi` from Chalk is `rustc_target::spec::abi::Abi`
- `Dynamic` actually lowers region
- Actually lower closures, with some tests. This doesn't 100% work, but can't confirm that's *only* because of closure lowering.
- Use `FxIndexSet` instead of `FxHashSet` in `chalk_fulfill`, which seems to have fixed the non-deterministic test error ordering. Guess we'll see on CI
- Actually implement `opaque_ty_data`, though I don't think this is sufficient for tests for them (I haven't added any)
- Uncomment some of the chalk tests that now work
Rollup merge of #73597 - ayazhafiz:i/const-span, r=ecstatic-morse
Record span of `const` kw in GenericParamKind
Context: this is needed for a fix of https://github.com/rust-lang/rustfmt/issues/4263,
which currently records the span of a const generic param incorrectly
because the location of the `const` kw is not known.
I am not sure how to add tests for this; any guidance in how to do so
would be appreciated :slightly_smiling_face:
Rollup merge of #73507 - mati865:cleanup-mingw-llvm-linkage, r=matthewjasper
Cleanup MinGW LLVM linkage workaround
LLVM correctly passes `uuid` for a long time, GCC unwinding library (either static or dynamic) comes from [windows_gnu_base](https://github.com/rust-lang/rust/blob/06e47688bf15d0215edbe05b21603062f6d2eb5d/src/librustc_target/spec/windows_gnu_base.rs).
Rollup merge of #73297 - ehuss:tool-warnings, r=Mark-Simulacrum
Support configurable deny-warnings for all in-tree crates.
This removes the hard-coded `deny(warnings)` on all in-tree tools, and allows it to be configured from the config. This is just a personal preference, as I find `deny(warnings)` frustrating during development or doing small tests.
This also fixes some regressions in terms of warning handling. Warnings used to be dependent on `SourceType`, but in #64316 it was changed to be based on `Mode`. This means tools like rustdoc no longer used the same settings as the rest of the tree. It also made `SourceType` useless since the only thing it was used for was warnings. I think it would be better for everything in the tree to use the same settings.
Rollup merge of #73102 - petrochenkov:flatgroup, r=Aaron1011
proc_macro: Stop flattening groups with dummy spans
Reduce the scope of the hack described in https://github.com/rust-lang/rust/issues/72545#issuecomment-640276791.
We still pass AST fragments to attribute and derive macros as single nonterminal tokens rather than as tokens streams, but now use a precise flag instead of the span-based heuristic that could do lead to incorrect behavior in unrelated cases.
https://github.com/rust-lang/rust/pull/73345 attempts to fully resolve this issue, but there are some compatibility issues to be addressed.
Rollup merge of #72967 - integer32llc:prevent-default-arrows, r=kinnison
Don't move cursor in search box when using arrows to navigate results
## What happens
- Go to https://doc.rust-lang.org/stable/std/index.html
- Press 's' to focus the search box
- Type a query like 'test'
- Press the down arrow one or more times to change which search result is highlighted
- Press the up arrow once to go up one search result
- Notice the cursor in the search box is now at the beginning of your query, such that if you now typed 'a' the search box would contain 'atest', when it would be expected that the cursor would have remained where it was and if you typed 'a' at this point it would result in 'testa'
- Press the down arrow once to go down one search result
- Now notice the cursor is at the end of your query again
## What I expected
I expected that changing which search result was highlighted using the up and down arrows would have no effect on where the cursor was in the search box.
## The fix
This PR prevents the default action of the up and down arrows when the custom keydown events are happening during a search.
bors [Fri, 26 Jun 2020 06:11:01 +0000 (06:11 +0000)]
Auto merge of #73743 - eddyb:lint-on-demand-typeck-tables, r=Manishearth
rustc_lint: only query `typeck_tables_of` when a lint needs it.
This was prompted by @jyn514 running into a situation where `rustdoc` wants to run the `unused_doc` lint without triggering type-checking (as an alternative to the "everybody loops" approach - type-checking may error/ICE because of the `rustdoc` feature of allowing multi-platform docs where the actual bodies of functions may refer to APIs for different platforms).
There was also this comment in the source:
```rust
// FIXME: Make this lazy to avoid running the TypeckTables query?
```
The main effect of this is for lint authors, who now need to use `cx.tables()` to get `&TypeckTables`, as opposed to having them always available in `cx.tables`.
Rollup merge of #73648 - poliorcetics:return-keyword, r=joshtriplett
Document the return keyword
Partial fix of #34601.
This documents the `return` keyword with two short example to explain it is not needed for the last expression in a function and a long example to show its use when interrupting a function execution early.
I did not put a link to the reference since the only link I found was https://doc.rust-lang.org/stable/reference/expressions/return-expr.html#return-expressions.
Rollup merge of #73621 - poliorcetics:mut-keyword, r=steveklabnik
Document the mut keyword
Partial fix for #34601.
Documentation for the `mut` keyword. I think it's okay for it to be quite short, this is not the book not the reference, but if you find something is missing, do not hesitate to tell me.
Rollup merge of #73460 - tmandry:variant-lineinfo, r=oli-obk
Emit line info for generator variants
Debuggers should be able to read a generator / async fn state machine and show the line it's suspended at. Eventually, this could grow into an "async stack trace" feature of sorts. While no debugger support this for Rust today, this PR adds the debuginfo necessary for that support to exist.
[This gist](https://gist.github.com/tmandry/6d7004fa008684f76809208847459f9b) shows the resulting debuginfo for a simple example. Here's a snippet:
The file and line have been added here. The line currently points to the beginning of the statement containing the yield (or await), because that's what the MIR source info points to for the yield terminator. (We may want to point to the yield or await line specifically, but that can be done independently of this change.)
Debuggers don't know how to use this kind of info yet. However, we're hoping to experiment with adding such support to Fuchsia's debugger. It would be exciting if someone were interested in adding similar to support to gdb/lldb.
Rollup merge of #73418 - doctorn:variants-intrinsic, r=kennytm
Add unstable `core::mem::variant_count` intrinsic
Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`.
I've shown this to a couple of people and they invariably ask 'why on earth?', but there's actually a very neat use case:
At the moment, if you want to create an opaque array type that's indexed by an `enum` with one element for each variant, you either have to hard-code the number of variants, add a `LENGTH` variant or use a `Vec`, none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic, it becomes possible to write the following:
Rollup merge of #72770 - crlf0710:mixed_script_confusable, r=Manishearth
Implement mixed script confusable lint.
This implements the mixed script confusable lint defined in RFC 2457.
This is blocked on #72069 and https://github.com/unicode-rs/unicode-security/pull/13, and will need a Cargo.toml version bump after those are resolved.
The lint message warning is sub-optimal for now. We'll need a mechanism to properly output `AugmentScriptSet` to screen, this is to be added in `unicode-security` crate.
Rollup merge of #72738 - mati865:self-contained-option, r=petrochenkov
Self contained linking option
With objects moved to self-contained directory by https://github.com/rust-lang/rust/pull/72999 we can now add option to control whether to use self-contained on native linkage mode.
Rollup merge of #72617 - eduardosm:panicking, r=Amanieu
Add a fast path for `std::thread::panicking`.
This is done by adding a global atomic variable (non-TLS) that counts how many threads are panicking. In order to check if the current thread is panicking, this variable is read and, if it is zero, no thread (including the one where `panicking` is being called) is panicking and `panicking` can return `false` immediately without needing to access TLS. If the global counter is not zero, the local counter is accessed from TLS to check if the current thread is panicking.
bors [Thu, 25 Jun 2020 22:52:59 +0000 (22:52 +0000)]
Auto merge of #71858 - petrochenkov:env, r=Mark-Simulacrum
Print environment variables accessed by rustc as special comments into depinfo files
So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes.
---
I've recently observed one more forgotten environment variable in a build script https://github.com/rust-lang/rust/pull/71314/commits/8a77d1ca3fc2df789157f7986ddbaf2a377ff0fe and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo.
Unsurprisingly, I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517 https://github.com/rust-lang/rust/issues/40364 https://github.com/rust-lang/rust/issues/44074.
Also, there are dozens of uses of `(option_)env!` in rustc repo and, like, half of them are not registered in build scripts.
---
Description:
- depinfo files are extended with special comments containing info about environment variables accessed during compilation.
- Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`.
- Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`).
- `KEY` and `VALUE` are minimally escaped (`\n`, `\r`, `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends.
Closes https://github.com/rust-lang/rust/issues/70517
Closes https://github.com/rust-lang/rust/issues/40364
Closes https://github.com/rust-lang/rust/issues/44074
A new issue in the cargo repo will be needed to track the cargo side of this feature.
bors [Thu, 25 Jun 2020 17:37:02 +0000 (17:37 +0000)]
Auto merge of #72717 - poliorcetics:try-from-int-to-nzint, r=dtolnay
Add TryFrom<{int}> for NonZero{int}
Adds `TryFrom<{int}> for NonZero{int}`.
It uses the existing `NonZero{int}::new()` and `Option::ok_or()` functions, meaning the checks are not repeated.
I also added tests, I tried to follow the convention I saw in the test file.
I also used `#[stable(feature = "nzint_try_from_int_conv", since = "1.46.0")]`, but I have no idea if the feature/version are correctly named or even correct.
David Wood [Thu, 25 Jun 2020 10:56:15 +0000 (11:56 +0100)]
emitter: column width defaults to 140
This commit modifies the column width computation in the emitter when
`termize::dimensions` returns `None` so that it uses the default value
of 140 (which is used in UI testing currently) instead of `usize::MAX`
which just ends up causing overflows in later computations. This is hard
to test but appears to produce the same output as using saturating
functions instead.
bors [Thu, 25 Jun 2020 08:58:37 +0000 (08:58 +0000)]
Auto merge of #72559 - Aaron1011:feature/assoc-lang-items, r=oli-obk
Implement associated lang items
Fixes #70718
This commit allows making associated items (e.g. associated functions
and types) into lang items via the `#[lang]` attribute. This allows such
items to be accessed directly, rather than by iterating over the parent
item's associated items.
I've added `FnOnce::Output` as a lang item, and updated one old usage to
use the new lang item. The remaining uses can be updated separately.
Dylan DPC [Thu, 25 Jun 2020 00:03:42 +0000 (02:03 +0200)]
Rollup merge of #73698 - spastorino:patch-1, r=wesleywiser
Add procedure for prioritization notifications on Zulip
This PR was originally opened by @LeSeulArtichaut as #73695, closing that one in favor of this one. Made some slight changes to it but can't push to @LeSeulArtichaut branch.
Dylan DPC [Thu, 25 Jun 2020 00:03:34 +0000 (02:03 +0200)]
Rollup merge of #73516 - Crabapple-iOS:feature/apple-dynamic-linking, r=nikomatsakis
Allow dynamic linking for iOS/tvOS targets
During the development and testing of the [Crabapple project](https://github.com/Crabapple-iOS/Crabapple), one obstacle was the lack of `cdylib` target support for iOS. Surprisingly, once `dynamic_linking` was enabled for iOS targets, it worked seemingly flawlessly.
I could not find any information on why this was initially or still is disabled.
Dylan DPC [Thu, 25 Jun 2020 00:03:32 +0000 (02:03 +0200)]
Rollup merge of #72700 - davidtwco:issue-66220-improper-ctypes-declarations, r=lcnr,varkor
`improper_ctypes_definitions` lint
Addresses #19834, #66220, and #66373.
This PR takes another attempt at #65134 (reverted in #66378). Instead of modifying the existing `improper_ctypes` lint to consider `extern "C" fn` definitions in addition to `extern "C" {}` declarations, this PR adds a new lint - `improper_ctypes_definitions` - which only applies to `extern "C" fn` definitions.
In addition, the `improper_ctype_definitions` lint differs from `improper_ctypes` by considering `*T` and `&T` (where `T: Sized`) FFI-safe (addressing #66220).
There wasn't a clear consensus in #66220 (where the issues with #65134 were primarily discussed) on the approach to take, but there has [been some discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2366220.20improper_ctypes.20definitions.20vs.20declarations/near/198903086). I fully expect that we'll want to iterate on this before landing.
cc @varkor + @shepmaster (from #19834) @hanna-kruppe (active in discussing #66220), @SimonSapin (#65134 caused problems for Servo, want to make sure that this PR doesn't)
Esteban Küber [Wed, 24 Jun 2020 23:17:04 +0000 (16:17 -0700)]
Suggest type param trait bound for binop only when appropriate
Verify that the binop trait *is* implemented for the types *if* all the
involved type parameters are replaced with fresh inferred types. When
this is the case, it means that the type parameter was indeed missing a
trait bound. If this is not the case, provide a generic `note` refering
to the type that doesn't implement the expected trait.
Aaron Hill [Mon, 25 May 2020 03:07:55 +0000 (23:07 -0400)]
Implement associated lang items
Fixes #70718
This commit allows making associated items (e.g. associated functions
and types) into lang items via the `#[lang]` attribute. This allows such
items to be accessed directly, rather than by iterating over the parent
item's associated items.
I've added `FnOnce::Output` as a lang item, and updated one old usage to
use the new lang item. The remaining uses can be updated separately.
Dylan DPC [Wed, 24 Jun 2020 12:28:47 +0000 (14:28 +0200)]
Rollup merge of #73675 - ehuss:update-books, r=ehuss
Update books
## reference
5 commits in 5d40ba5c2515caffa7790cda621239dc21ef5a72..04d5d5d7ba624b6f5016298451f3a63d557f3260
2020-06-06 20:25:36 -0700 to 2020-06-16 15:08:05 -0700
- Mention `feature="foo"` is a Cargo convention. (rust-lang-nursery/reference#833)
- fix out of date info on type aliases (rust-lang-nursery/reference#831)
- Fix an invalid variable name in the loop example (rust-lang-nursery/reference#832)
- Fix note about using proc_macro with Cargo. (rust-lang-nursery/reference#815)
- Add a link to the definition of Pattern_White_Space. (rust-lang-nursery/reference#824)
## book
7 commits in 30cd9dfe71c446de63826bb4472627af45acc9db..4e7c00bece1544d409312ec93467beb62b5bd0cb
2020-06-07 23:07:19 -0500 to 2020-06-19 09:39:12 -0400
- Link to the reference file that exists
- Link to the reference
- Clean up discussion around advanced lifetime stuff (rust-lang/book#2351)
- Reword Chapter 6 page 2, match (rust-lang/book#2374)
- Clarify some package/crate distinctions in chapter 14 (rust-lang/book#2373)
- Not mandatory with cargo 1.41.0-nightly (rust-lang/book#2368)
- Use same naming for Rhs as libcore/ops (rust-lang/book#2371)
## rust-by-example
4 commits in 7aa82129aa23e7e181efbeb8da03a2a897ef6afc..6f94ccb48da6fa4ed0031290f21411cf789f7d5e
2020-05-25 14:54:26 -0300 to 2020-06-20 17:51:30 -0300
- Update to mdbook 0.3.7 (rust-lang/rust-by-example#1352)
- Update fn.md (rust-lang/rust-by-example#1351)
- Fixed typo in formatted print (rust-lang/rust-by-example#1350)
- This explanation incorrectly inverts the meaning of SuperTrait (rust-lang/rust-by-example#1349)
## embedded-book
5 commits in 5555a97f04ad7974ac6fb8fb47c267c4274adf4a..616962ad0dd80f34d8b802da038d0aed9dd691bb
2020-05-25 18:00:51 +0000 to 2020-06-23 16:03:45 +0000
- Update RTFM name to RTIC, fixed links, updated singletons.md example. (rust-embedded/book#254)
- Note on how to rebuild if memory.x is changed (rust-embedded/book#253)
- Ease the readers into the Discovery book (rust-embedded/book#250)
- Provide a note on 'extern crate' usage in edition 2018 syntax of Rust (rust-embedded/book#248)
- Fix Typos and Improve Readability (rust-embedded/book#245)
Dylan DPC [Wed, 24 Jun 2020 12:28:45 +0000 (14:28 +0200)]
Rollup merge of #73667 - nrabulinski:master, r=Dylan-DPC
Update BTreeMap::new() doc
Updates the documentation according to [this comment](https://github.com/rust-lang/rust/pull/72876/files/0c5c644c91edf6ed949cfa5ffc524f43369df604#r433232581) on #72876
Dylan DPC [Wed, 24 Jun 2020 12:28:43 +0000 (14:28 +0200)]
Rollup merge of #73652 - da-x:add-reexported-to-use-suggestions, r=petrochenkov
Add re-exports to use suggestions
In the following example, an inaccessible path is suggested via `use foo::bar::X;` whereas an accessible public exported path can be suggested instead.
```rust
mod foo {
mod bar {
pub struct X;
}
pub use self::bar::X;
}
Dylan DPC [Wed, 24 Jun 2020 12:28:39 +0000 (14:28 +0200)]
Rollup merge of #73639 - ayazhafiz:i/73553, r=davidtwco
Change heuristic for determining range literal
Currently, rustc uses a heuristic to determine if a range expression is
not a literal based on whether the expression looks like a function call
or struct initialization. This fails for range literals whose
lower/upper bounds are the results of function calls. A possibly-better
heuristic is to check if the expression contains `..`, required in range
literals.
Of course, this is also not perfect; for example, if the range
expression is a struct which includes some text with `..` this will
fail, but in general I believe it is a better heuristic.
A better alternative altogether is to add the `QPath::LangItem` enum
variant suggested in #60607. I would be happy to do this as a precursor
to this patch if someone is able to provide general suggestions on how
usages of `QPath` need to be changed later in the compiler with the
`LangItem` variant.
David Wood [Sun, 21 Jun 2020 19:30:41 +0000 (20:30 +0100)]
improper_ctypes: only allow params in defns mode
This commit adjusts the behaviour introduced in a previous commit so
that generic parameters and projections are only allowed in the
definitions mode - and are otherwise a bug. Generic parameters in
declarations are prohibited earlier in the compiler, so if that branch
were reached, it would be a bug.
David Wood [Thu, 28 May 2020 14:57:09 +0000 (15:57 +0100)]
lints: add `improper_ctypes_definitions`
This commit adds a new lint - `improper_ctypes_definitions` - which
functions identically to `improper_ctypes`, but on `extern "C" fn`
definitions (as opposed to `improper_ctypes`'s `extern "C" {}`
declarations).
bors [Wed, 24 Jun 2020 01:24:38 +0000 (01:24 +0000)]
Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture, r=petrochenkov
Always capture tokens for `macro_rules!` arguments
When we invoke a proc-macro, the `TokenStream` we pass to it may contain 'interpolated' AST fragments, represented by `rustc_ast::token::Nonterminal`. In order to correctly, pass a `Nonterminal` to a proc-macro, we need to have 'captured' its `TokenStream` at the time the AST was parsed.
Currently, we perform this capturing when attributes are present on items and expressions, since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However, `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros, we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081).
This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro, so this is needed to ensure that tokens will always be available when they are needed.
This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081, this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans.
In this case, Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)), which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084.
This regression manifests itself as the following error:
```
[INFO] [stdout] error: proc macro panicked
[INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34
[INFO] [stdout] |
[INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar));
[INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[INFO] [stdout] |
[INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value
[INFO] [stdout] = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
```
It can be fixed by running `cargo update -p pear`, which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression).
Split out from https://github.com/rust-lang/rust/pull/73084/
projects / rust.git / log