| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
With NLL region kinds are always ReVar
|
|
Reword when `_` couldn't be inferred
r? @nikomatsakis
|
|
|
|
|
|
|
|
This commit stabilizes the `#[wasm_import_module]` attribute as
`#[link(wasm_import_module = "...")]`. Tracked by #52090 this new directive in
the `#[link]` attribute is used to configured the module name that the imports
are listed with. The WebAssembly specification indicates two utf-8 names are
associated with all imported items, one for the module the item comes from and
one for the item itself. The item itself is configurable in Rust via its
identifier or `#[link_name = "..."]`, but the module name was previously not
configurable and defaulted to `"env"`. This commit ensures that this is also
configurable.
Closes #52090
|
|
The link for comparison:
- https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types--sized (broken)
- https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-sized (fixed)
This commit is the result of (first) searching via:
find src -type f -print0 | xargs -0 fgrep -l dynamically-sized-types--sized
and then replacing all relevant occurrences via:
find src/{libcore,test/ui} -type f -print0 | xargs -0 sed -i.bak \
s/dynamically-sized-types--sized/dynamically-sized-types-and-sized/g
find src/{libcore,test/ui} -type f -name '*.bak' -print0 | xargs -0 rm
(Note: Commands run on macOS 10.13 (BSD). `sed -i.bak` should work on
GNU/Linux as well, but not tested.)
|
|
improve error message shown for unsafe operations
Add a short explanation saying why undefined behavior could arise. In particular, the error many people got for "creating a pointer to a packed field requires unsafe block" was not worded great -- it lead to people just adding the unsafe block without considering if what they are doing follows the rules.
I am not sure if a "note" is the right thing, but that was the easiest thing to add...
Inspired by @gnzlbg at https://github.com/rust-lang/rust/issues/46043#issuecomment-381544673
|
|
|
|
behavior could arise
Inspired by @gnzlbg at https://github.com/rust-lang/rust/issues/46043#issuecomment-381544673
|
|
r=nikomatsakis
Dont run ast borrowck on mir mode
r? @nikomatsakis
|
|
|
|
|
|
r=petrochenkov
add modifier keyword spans to hir::Visibility; improve unreachable-pub, private-no-mangle lint suggestions
#50455 pointed out that the unreachable-pub suggestion for brace-grouped `use`s was bogus; #50476 partially ameliorated this by marking the suggestion as `Applicability::MaybeIncorrect`, but this is the actual fix.
Meanwhile, another application of having spans available in `hir::Visibility` is found in the private-no-mangle lints, where we can now issue a suggestion to use `pub` if the item has a more restricted visibility marker (this seems much less likely to come up in practice than not having any visibility keyword at all, but thoroughness is a virtue). While we're there, we can also add a helpful note if the item does have a `pub` (but triggered the lint presumably because enclosing modules were private).
r? @nrc
cc @Manishearth
|
|
April 2016's Issue #33174 called out the E0446 diagnostics as
confusing. While adding the name of the restricted type to the message
(548e681f) clarified matters somewhat, Esteban Küber pointed out that we
could stand to place a secondary span on the restricted type.
Here, we differentiate between crate-visible, truly private, and
otherwise restricted types, and place a secondary span specifically on
the visibility modifier of the restricted type's declaration (which we
can do now that HIR visibilities have spans!).
At long last, this resolves #33174.
|
|
Updated tests accordingly.
|
|
Point to lifetime spans on lifetime errors
|
|
|
|
|
|
|
|
Don't inspect the generated existential type items
r? @nikomatsakis
My debugging led me to the `hir::ItemExistential(..)` checks, which are entirely unnecessary because we never use the items directly. The issue was that items were iterated over in a random order (due to hashmaps), so if you checked the `ItemExistential` before the function that has the actual return `impl Trait`, you'd run into those ICEs you encountered.
|
|
These were stabilized in March 2018's #47813, and are the Preferred Way
to Do It going forward (q.v. #51043).
|
|
|
|
Add error for using null characters in #[export_name]
Fixes #51741.
|
|
The `dyn Trait` syntax was stabilized in 199ee327. Resolves #49277.
|
|
|
|
|
|
Various changes to existing diagnostics
* [Add code to `invalid ABI` error, add span label, move list to help to make message shorter](https://github.com/rust-lang/rust/pull/51463/commits/23ae5af274defa9ff884f593e44a2bbcaf814a02):
```
error[E0697]: invalid ABI: found `路濫狼á́́`
--> $DIR/unicode.rs:11:8
|
LL | extern "路濫狼á́́" fn foo() {} //~ ERROR invalid ABI
| ^^^^^^^^^ invalid ABI
|
= help: valid ABIs: cdecl, stdcall, fastcall, vectorcall, thiscall, aapcs, win64, sysv64, ptx-kernel, msp430-interrupt, x86-interrupt, Rust, C, system, rust-intrinsic, rust-call, platform-intrinsic, unadjusted
```
* [Add code to incorrect `pub` restriction error](https://github.com/rust-lang/rust/pull/51463/commits/e96fdea8a38f39f99f8b9a4000a689187a457e08)
* [Add message to `rustc_on_unimplemented` attributes in core to have them set a custom message _and_ label](https://github.com/rust-lang/rust/pull/51463/commits/2cc7e5ed307aee936c20479cfdc7409d6b52a464):
```
error[E0277]: `W` does not have a constant size known at compile-time
--> $DIR/unsized-enum2.rs:33:8
|
LL | VA(W),
| ^ `W` does not have a constant size known at compile-time
|
= help: the trait `std::marker::Sized` is not implemented for `W`
= help: consider adding a `where W: std::marker::Sized` bound
= note: no field of an enum variant may have a dynamically sized type
```
```
error[E0277]: `Foo` cannot be sent between threads safely
--> $DIR/E0277-2.rs:26:5
|
LL | is_send::<Foo>();
| ^^^^^^^^^^^^^^ `Foo` cannot be sent between threads safely
|
= help: the trait `std::marker::Send` is not implemented for `Foo`
```
```
error[E0277]: can't compare `{integer}` with `std::string::String`
--> $DIR/binops.rs:16:7
|
LL | 5 < String::new();
| ^ no implementation for `{integer} < std::string::String` and `{integer} > std::string::String`
|
= help: the trait `std::cmp::PartialOrd<std::string::String>` is not implemented for `{integer}`
```
```
error[E0277]: can't compare `{integer}` with `std::result::Result<{integer}, _>`
--> $DIR/binops.rs:17:7
|
LL | 6 == Ok(1);
| ^^ no implementation for `{integer} == std::result::Result<{integer}, _>`
|
= help: the trait `std::cmp::PartialEq<std::result::Result<{integer}, _>>` is not implemented for `{integer}`
```
```
error[E0277]: a collection of type `i32` cannot be built from an iterator over elements of type `i32`
--> $DIR/type-check-defaults.rs:16:19
|
LL | struct WellFormed<Z = Foo<i32, i32>>(Z);
| ^ a collection of type `i32` cannot be built from `std::iter::Iterator<Item=i32>`
|
= help: the trait `std::iter::FromIterator<i32>` is not implemented for `i32`
note: required by `Foo`
--> $DIR/type-check-defaults.rs:15:1
|
LL | struct Foo<T, U: FromIterator<T>>(T, U);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
* [Add link to book for `Sized` errors](https://github.com/rust-lang/rust/pull/51463/commits/1244dc7c283323aea1a3457a4458d590a3e160c8):
```
error[E0277]: `std::fmt::Debug + std::marker::Sync + 'static` does not have a constant size known at compile-time
--> $DIR/const-unsized.rs:13:29
|
LL | const CONST_0: Debug+Sync = *(&0 as &(Debug+Sync));
| ^^^^^^^^^^^^^^^^^^^^^^ `std::fmt::Debug + std::marker::Sync + 'static` does not have a constant size known at compile-time
|
= help: the trait `std::marker::Sized` is not implemented for `std::fmt::Debug + std::marker::Sync + 'static`
= note: to learn more, visit <https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types--sized>
= note: constant expressions must have a statically known size
```
* [Point to previous line for single expected token not found](https://github.com/rust-lang/rust/pull/51463/commits/48165168fb0f059d8536cd4a2276b609d4a7f721) (if the current token is in a different line)
|
|
do not ICE when existing type info is incomplete
Apparently master is kinda ICE-y right now, but only for some people (sadly that set includes me).
I'm not crazy about this PR, because it seems to regress diagnostics a lot, but it *does* fix the problems. I think probably fixing the diagnostics should be done by doing a better job of suppressing errors?
Mitigates #51683
r? @oli-obk
|
|
The Great Generics Generalisation: HIR Edition
This is essentially a followup to https://github.com/rust-lang/rust/pull/45930, consolidating the use of separate lifetime and type vectors into single kinds vectors wherever possible. This is intended to provide more of the groundwork for const generics (https://github.com/rust-lang/rust/issues/44580).
r? @eddyb
cc @yodaldevoid
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Suggest parentheses when a struct literal needs them
When writing a struct literal in an expression that expects a block to
be started afterwards (like an `if` statement), do not suggest using the
same struct literal:
```
did you mean `S { /* fields * /}`?
```
Instead, suggest surrounding the expression with parentheses:
```
did you mean `(S { /* fields * /})`?
```
Fix #47360, #50090. Leaving #42982 open to come back to this problem with a better solution.
|
|
|
|
When writing a struct literal in an expression that expects a block to
be started afterwards (like an `if` statement), do not suggest using the
same struct literal:
```
did you mean `S { /* fields * /}`?
```
Instead, suggest surrounding the expression with parentheses:
```
did you mean `(S { /* fields * /})`?
```
|
|
|
|
r=nikomatsakis
make ui tests robust with respect to NLL
This PR revises the `ui` tests that I could quickly identify that:
1. previously had successful compilations under non-lexical lifetimes (NLL) because they assumed lexical lifetimes, but
2. such assumption of lexical lifetimes was actually not necessarily part of the spirit of the original issue/bug we want to witness.
In many cases, this is simply a matter of adding a use of a borrow so that it gets extended long enough to observe a conflict.
(In some cases the revision was more subtle, such as adding a destructor, or revising the order of declaration of some variables.)
----
With these test revisions in place, I subsequently updated the expected stderr output under the NLL compiletest mode. So now we should get even more testing of NLL than we were before.
Fix #51025
|
|
|
|
Tweak the spans for error when finding type arguments or where clauses
in main and start functions.
|
|
Prevent main from having a where clause.
Closes #50714
Should this have a crater run?
cc #48557, #48214
r? @nikomatsakis
|
|
|
