Aaron Hill [Mon, 2 Nov 2020 06:37:26 +0000 (01:37 -0500)]
Fix ICE when a future-incompat-report has its command-line level capped
Fixes #78660
With PR https://github.com/rust-lang/rust/pull/75534 merged, we now run
more lint-related code for future-incompat-report, even when their final
level is Allow. Some lint-related code was not expecting `Level::Allow`,
and had an explicit panic.
This PR explicitly tracks the lint level set on the command line before
`--cap-lints` is applied. This is used to emit a more precise error
note (e.g. we don't say that `-W lint-name` was specified on the
command line just because a lint was capped to Warn). As a result, we
can now correctly emit a note that `-A` was used if we got
`Level::Allow` from the command line (before the cap is applied).
bors [Sun, 1 Nov 2020 16:52:28 +0000 (16:52 +0000)]
Auto merge of #75534 - Aaron1011:feature/new-future-breakage, r=pnkfelix
Implement rustc side of report-future-incompat
cc https://github.com/rust-lang/rust/issues/71249
This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch :smile: ).
My approach outputs the entire original `Diagnostic`, in a way that is compatible with incremental compilation. This is not yet integrated with compiletest, but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`.
Several changes are made to support this feature:
* The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`.
* The `Lint` struct is extended with an `Option<FutureBreakage>`. When present, it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently, a `date` field indicating when the crate will stop compiling).
* A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place, while still discarding them before they are passed to the `Emitter`.
* `DiagnosticId::Lint` is extended with a `has_future_breakage` field, indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report).
* `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint`, to retrieve the `FutureBreakage` data.
Currently, `FutureBreakage.date` is always set to `None`. However, this could potentially be interpreted by Cargo in the future.
I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint, which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself.
bors [Sun, 1 Nov 2020 14:37:50 +0000 (14:37 +0000)]
Auto merge of #78553 - Nadrieril:fix-78549, r=varkor
Fix #78549
Before #78430, this worked because `specialize_constructor` didn't actually care too much which constructor was passed to it unless needed. That PR however handles `&str` as a special case, and I did not anticipate patterns for the `&str` type other than string literals.
I am not very confident there are not other similar oversights left, but hopefully only `&str` was different enough to break my assumptions.
bors [Sun, 1 Nov 2020 11:54:58 +0000 (11:54 +0000)]
Auto merge of #78623 - m-ou-se:rollup-m6y5j0m, r=m-ou-se
Rollup of 6 pull requests
Successful merges:
- #78073 (Add #[inline] to some functions in core::str.)
- #78596 (Fix doc links to std::fmt)
- #78599 (Add note to process::arg[s] that args shouldn't be escaped or quoted)
- #78602 (fix various aliasing issues in the standard library)
- #78603 (expand: Tweak a comment in implementation of `macro_rules`)
- #78621 (Inline Default::default() for atomics)
Mara Bos [Sun, 1 Nov 2020 10:53:39 +0000 (11:53 +0100)]
Rollup merge of #78621 - solson:inline, r=m-ou-se
Inline Default::default() for atomics
Functions like `AtomicUsize::default()` are not cross-crate inlineable before this PR ([see assembly output here](https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=e353321766418f759c69fb141d3732f8)), which can lead to unexpected performance issues when initializing a large array using this function, e.g. as seen [here](https://github.com/spacejam/sled/blob/d513996a85875be8c813fd0e30a548b89682289a/src/histogram.rs#L53) which should turn into a simple loop writing zeroes but doesn't.
Mara Bos [Sun, 1 Nov 2020 10:53:37 +0000 (11:53 +0100)]
Rollup merge of #78603 - petrochenkov:fourdigits, r=matthewjasper
expand: Tweak a comment in implementation of `macro_rules`
The answer to the removed FIXME is that we don't apply mark to the span `sp` just because that span is no longer used. We could apply it, but that would just be unnecessary extra work.
The comments in code tell why the span is unused, it's a span of `$var` literally, which is lost for `tt` variables because their tokens are outputted directly, but kept for other variables which are outputted as [groups](https://doc.rust-lang.org/nightly/proc_macro/struct.Group.html) and `sp` is kept as the group's span.
Mara Bos [Sun, 1 Nov 2020 10:53:36 +0000 (11:53 +0100)]
Rollup merge of #78602 - RalfJung:raw-ptr-aliasing-issues, r=m-ou-se
fix various aliasing issues in the standard library
This fixes various cases where the standard library either used raw pointers after they were already invalidated by using the original reference again, or created raw pointers for one element of a slice and used it to access neighboring elements.
Mara Bos [Sun, 1 Nov 2020 10:53:34 +0000 (11:53 +0100)]
Rollup merge of #78599 - panstromek:master, r=m-ou-se
Add note to process::arg[s] that args shouldn't be escaped or quoted
This came out of discussion on [forum](https://users.rust-lang.org/t/how-to-get-full-output-from-command/50626), where I recently asked a question and it turned out that the problem was redundant quotation:
```rust
Command::new("rg")
.arg("\"pattern\"") // this will look for "pattern" with quotes included
```
This is something that has bitten me few times already (in multiple languages actually), so It'd be grateful to have it in the docs, even though it's not sctrictly Rust specific problem. Other users also agreed.
This can be really annoying to debug, because in many cases (inluding mine), quotes can be legal part of the argument, so the command doesn't fail, it just behaves unexpectedly. Not everybody (including me) knows that quotes around arguments are part of the shell and not part of the called program. Coincidentally, somoene had the same problem [yesterday](https://www.reddit.com/r/rust/comments/jkxelc/going_crazy_over_running_a_curl_process_from_rust/) on reddit.
I am not a native speaker, so I welcome any corrections or better formulation, I don't expect this to be merged as is. I was also reminded that this is platform/shell specific behaviour, but I didn't find a good way to formulate that briefly, any ideas welcome.
It's also my first PR here, so I am not sure I did everything correctly, I did this just from Github UI.
Mara Bos [Sun, 1 Nov 2020 10:53:33 +0000 (11:53 +0100)]
Rollup merge of #78596 - pavlukivan:master, r=m-ou-se
Fix doc links to std::fmt
`std::format` and `core::write` macros' docs linked to `core::fmt` for format string reference, even though only `std::fmt` has format string documentation (and the link titles were `std::fmt`)
bors [Sun, 1 Nov 2020 09:30:11 +0000 (09:30 +0000)]
Auto merge of #78531 - cuviper:unwrap-metadata, r=tmandry
rustc_llvm: unwrap LLVMMetadataRef before casting
Directly casting the opaque pointer was [reported] to cause an
"incomplete type" error with GCC 9.3:
```
llvm-wrapper/RustWrapper.cpp:939:31: required from here
/usr/include/c++/9.3/type_traits:1301:12: error: invalid use of incomplete type 'struct LLVMOpaqueMetadata'
1301 | struct is_base_of
| ^~~~~~~~~~
In file included from [...]/rust/src/llvm-project/llvm/include/llvm-c/BitReader.h:23,
from llvm-wrapper/LLVMWrapper.h:1,
from llvm-wrapper/RustWrapper.cpp:1:
[...]/rust/src/llvm-project/llvm/include/llvm-c/Types.h:89:16: note: forward declaration of 'struct LLVMOpaqueMetadata'
89 | typedef struct LLVMOpaqueMetadata *LLVMMetadataRef;
| ^~~~~~~~~~~~~~~~~~
```
bors [Sun, 1 Nov 2020 06:49:16 +0000 (06:49 +0000)]
Auto merge of #78420 - estebank:suggest-assoc-fn, r=petrochenkov
Suggest calling associated `fn` inside `trait`s
When calling a function that doesn't exist inside of a trait's
associated `fn`, and another associated `fn` in that trait has that
name, suggest calling it with the appropriate fully-qualified path.
Expand the label to be more descriptive.
Prompted by the following user experience:
https://users.rust-lang.org/t/cannot-find-function/50663
Nadrieril [Sun, 1 Nov 2020 01:58:48 +0000 (01:58 +0000)]
Fix #78549
Before #78430, string literals worked because `specialize_constructor`
didn't actually care too much which constructor was passed to it unless
needed. Since then, string literals are special cased and a bit hacky. I
did not anticipate patterns for the `&str` type other than string
literals, hence this bug. This makes string literals less hacky.
bors [Sat, 31 Oct 2020 17:09:38 +0000 (17:09 +0000)]
Auto merge of #78594 - m-ou-se:rollup-h5c8frs, r=m-ou-se
Rollup of 7 pull requests
Successful merges:
- #74622 (Add std::panic::panic_any.)
- #77099 (make exp_m1 and ln_1p examples more representative of use)
- #78526 (Strip tokens from trait and impl items before printing AST JSON)
- #78550 (x.py setup: Create config.toml in the current directory, not the top-level directory)
- #78577 (validator: Extend aliasing check to a call terminator)
- #78581 (Constantify more BTreeMap and BTreeSet functions)
- #78587 (parser: Cleanup `LazyTokenStream` and avoid some clones)
Anthony Ramine [Mon, 26 Oct 2020 19:55:07 +0000 (20:55 +0100)]
Implement -Z relax-elf-relocations=yes|no
This lets rustc users tweak whether the linker should relax ELF relocations,
namely whether it should emit R_X86_64_GOTPCRELX relocations instead of
R_X86_64_GOTPCREL, as the former is allowed by the ABI to be further
optimised. The default value is whatever the target defines.
Ivan Pavluk [Sat, 31 Oct 2020 10:50:08 +0000 (17:50 +0700)]
Fix doc links to std::fmt
std::format and core::write macros' docs linked to core::fmt for format string reference, even though only std::fmt has format string documentation and the link titles were std::fmt.
Mara Bos [Sat, 31 Oct 2020 08:49:32 +0000 (09:49 +0100)]
Rollup merge of #77099 - tspiteri:exp_m1-examples, r=m-ou-se
make exp_m1 and ln_1p examples more representative of use
With this PR, the examples for `exp_m1` would fail if `x.exp() - 1.0` is used instead of `x.exp_m1()`, and the examples for `ln_1p` would fail if `(x + 1.0).ln()` is used instead of `x.ln_1p()`.
Mara Bos [Sat, 31 Oct 2020 08:49:28 +0000 (09:49 +0100)]
Rollup merge of #74622 - fusion-engineering-forks:panic-box, r=KodrAus
Add std::panic::panic_any.
The discussion of #67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads, to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`.
bors [Fri, 30 Oct 2020 14:24:02 +0000 (14:24 +0000)]
Auto merge of #78424 - jyn514:THE-PAPERCLIP-COMETH, r=davidtwco
Fix some more clippy warnings
Found while working on https://github.com/rust-lang/rust/pull/77351. It turns out that `x.py clippy --fix` does work on that branch as long as you pass `CARGOFLAGS=--lib`.
Yuki Okushi [Fri, 30 Oct 2020 09:00:45 +0000 (18:00 +0900)]
Rollup merge of #77888 - LingMan:ast_pretty_tt_prepend_space, r=jyn514
Simplify a nested bool match
Logically this first eliminates the innermost match by merging the patterns.
Then, in a second step, turns the newly innermost match into a `matches!` call.
bors [Fri, 30 Oct 2020 07:05:57 +0000 (07:05 +0000)]
Auto merge of #78393 - SNCPlay42:match-if-guard, r=tmandry
Always record reference to binding in match if guards
When encountering a binding from a `match` pattern in its `if` guard when computing a generator's interior types, we must always record the type of a reference to the binding because of how `if` guards are lowered to MIR. This was missed in #75213 because the binding in that test case was autorefed and we recorded that adjusted type anyway.
Josh Stone [Thu, 29 Oct 2020 16:45:15 +0000 (09:45 -0700)]
rustc_llvm: unwrap LLVMMetadataRef before casting
Directly casting the opaque pointer was [reported] to cause an
"incomplete type" error with GCC 9.3:
```
llvm-wrapper/RustWrapper.cpp:939:31: required from here
/usr/include/c++/9.3/type_traits:1301:12: error: invalid use of incomplete type 'struct LLVMOpaqueMetadata'
1301 | struct is_base_of
| ^~~~~~~~~~
In file included from [...]/rust/src/llvm-project/llvm/include/llvm-c/BitReader.h:23,
from llvm-wrapper/LLVMWrapper.h:1,
from llvm-wrapper/RustWrapper.cpp:1:
[...]/rust/src/llvm-project/llvm/include/llvm-c/Types.h:89:16: note: forward declaration of 'struct LLVMOpaqueMetadata'
89 | typedef struct LLVMOpaqueMetadata *LLVMMetadataRef;
| ^~~~~~~~~~~~~~~~~~
```
In #75671 `clippy::temporary_cstr_as_ptr` was removed instead of being deprecated. This will trigger an error (unknown lint) for users that refer to that lint to e.g. allow it, instead of a more informative warning.
Jonas Schievink [Thu, 29 Oct 2020 16:05:28 +0000 (17:05 +0100)]
Rollup merge of #78499 - SkiFire13:fix-string-retain, r=m-ou-se
Prevent String::retain from creating non-utf8 strings when abusing panic
Fixes #78498
The idea is the same as `Vec::drain`, set the len to 0 so that nobody can observe the broken invariant if it escapes the function (in this case if `f` panics)
Jonas Schievink [Thu, 29 Oct 2020 16:05:26 +0000 (17:05 +0100)]
Rollup merge of #78493 - ehuss:update-cargo, r=ehuss
Update cargo
8 commits in dd83ae55c871d94f060524656abab62ec40b4c40..becb4c282b8f37469efb8f5beda45a5501f9d367
2020-10-20 19:31:26 +0000 to 2020-10-28 16:41:55 +0000
- List available packages if providing `--package` with an empty value (rust-lang/cargo#8808)
- Add a future-compatibility warning on allowed feature name characters. (rust-lang/cargo#8814)
- New namespaced features implementation. (rust-lang/cargo#8799)
- Remove redundant "For example, " (rust-lang/cargo#8810)
- Document platform-specific build-dependencies (rust-lang/cargo#8809)
- Remove some unused code. (rust-lang/cargo#8807)
- Some minor clippy fixes. (rust-lang/cargo#8804)
- Update TOML website links. (rust-lang/cargo#8803)
Jonas Schievink [Thu, 29 Oct 2020 16:05:23 +0000 (17:05 +0100)]
Rollup merge of #78462 - danielframpton:fixnullisa, r=nagisa
Use unwrapDIPtr because the Scope may be null.
I ran into an assertion when using debug information on Windows with LLVM assertions enabled.
It seems like we are using unwrap here (which in turn calls isa and requires the pointer to be non-null) but we expect the value to be null because that is what we are passing from rustc.
This change uses unwrapDIPtr which explicitly allows nullptr.
The FFI prototype for this method on the rust side has the `LLVMMetadataRef` parameter as `Scope: Option<&'a DIScope>`, and we always pass `None` when `msvc_like_names` is true.
Jonas Schievink [Thu, 29 Oct 2020 16:05:17 +0000 (17:05 +0100)]
Rollup merge of #78423 - tgnottingham:caching_source_map_bounds_check, r=oli-obk
rustc_span: improve bounds checks in byte_pos_to_line_and_col
The effect of this change is to consider edge-case spans that start or
end at the position one past the end of a file to be valid during span
hashing and encoding. This change means that these spans will be
preserved across incremental compilation sessions when they are part of
a serialized query result, instead of causing the dummy span to be used.
Jonas Schievink [Thu, 29 Oct 2020 16:05:11 +0000 (17:05 +0100)]
Rollup merge of #78244 - workingjubilee:dogfood-fancy-ranges, r=varkor
Dogfood {exclusive,half-open} ranges in compiler (nfc)
In particular, this allows us to write more explicit matches that
avoid the pitfalls of using a fully general fall-through case, yet
remain fairly ergonomic. Less logic is in guard cases, more is in
the actual exhaustive case analysis.
Jonas Schievink [Thu, 29 Oct 2020 16:05:00 +0000 (17:05 +0100)]
Rollup merge of #75078 - ijackson:slice-strip, r=steveklabnik
Improve documentation for slice strip_* functions
Prompted by the stabilisation tracking issue #73413 I looked at the docs for `strip_prefix` and `strip_suffix` for both `str` and `slice`, and I felt they could be slightly improved.
bors [Thu, 29 Oct 2020 12:08:16 +0000 (12:08 +0000)]
Auto merge of #78446 - RalfJung:box, r=Amanieu
fix Box::into_unique
https://github.com/rust-lang/rust/pull/77187/ broke Stacked Borrows pointer tagging around `Box::into_unique` (this is caused by `Box` being a special case in the type system, which box-internal code needs to account for). This PR fixes that.