Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update master #2

Merged
merged 10,000 commits into from
Jun 26, 2020
Merged

update master #2

merged 10,000 commits into from
Jun 26, 2020

Conversation

TyPR124
Copy link
Owner

@TyPR124 TyPR124 commented Jun 26, 2020

No description provided.

jumbatm and others added 30 commits June 20, 2020 16:54
- Allow ClashingExternDecl for lint-dead-code-3
- Update test case for #5791
- Update test case for #1866
- Update extern-abi-from-macro test case
This commit normalizes projections which contain opaque types (opaque types
are otherwise linted against, which is would have previously made the
test cases added in this commit fail).

Signed-off-by: David Wood <david@davidtw.co>
We now require that projection candidates are applicable with the
idenitity substs of the trait, rather than allowing predicates that are
only applicable for certain substs.
This was currently only happening due to eager normalization, which
isn't possible if there's specialization or bound variables.
ehuss and others added 28 commits June 23, 2020 19:59
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).

Signed-off-by: David Wood <david@davidtw.co>
This commit changes the improper ctypes lint (when operating on
definitions) to consider raw pointers or references to sized types as
FFI-safe.

Signed-off-by: David Wood <david@davidtw.co>
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.

Signed-off-by: David Wood <david@davidtw.co>
Update cargo

9 commits in 089cbb80b73ba242efdcf5430e89f63fa3b5328d..c26576f9adddd254b3dd63aecba176434290a9f6
2020-06-15 14:38:34 +0000 to 2020-06-23 16:21:21 +0000
- Adding environment variable CARGO_PKG_LICENSE_FILE (rust-lang/cargo#8387)
- Enable "--target-dir" in "cargo install" (rust-lang/cargo#8391)
- Add support for `workspace.metadata` table (rust-lang/cargo#8323)
- Fix overzealous `clean -p` for reserved names. (rust-lang/cargo#8398)
- Fix order-dependent feature resolution. (rust-lang/cargo#8395)
- Correct mispelling of `cargo`. (rust-lang/cargo#8389)
- Add missing license field. (rust-lang/cargo#8386)
- Adding environment variable CARGO_PKG_LICENSE (rust-lang/cargo#8325)
- Cut down on data fetch from git dependencies (rust-lang/cargo#8363)
…sakis

Remove unused crate imports in 2018 edition crates

Closes #73570
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.

Closes #73553
Add some regression tests

Closes #44861
Closes #51506
Closes #59435
Closes #69840
…trochenkov

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;
}

fn main() { X; }
```

This fixes the issue.
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/reference#833)
- fix out of date info on type aliases (rust-lang/reference#831)
- Fix an invalid variable name in the loop example (rust-lang/reference#832)
- Fix note about using proc_macro with Cargo. (rust-lang/reference#815)
- Add a link to the definition of Pattern_White_Space. (rust-lang/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)
Rollup of 6 pull requests

Successful merges:

 - #73638 (Remove unused crate imports in 2018 edition crates)
 - #73639 (Change heuristic for determining range literal)
 - #73646 (Add some regression tests)
 - #73652 (Add re-exports to use suggestions)
 - #73667 (Update BTreeMap::new() doc)
 - #73675 (Update books)

Failed merges:

r? @ghost
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.
…ations, 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)
… 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.
Add UI test for issue 73592

It happens that #72280 accidentally fixed a bug which is later discovered in #73592. This PR adds a UI test to prevent future regression.

Closes #73592
Document the self keyword

Partial fix of #34601.

This documents the `self` keyword, adding several examples and a link to the reference.
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.

r? @wesleywiser @rust-lang/wg-prioritization
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.
Rollup of 6 pull requests

Successful merges:

 - #72700 (`improper_ctypes_definitions` lint)
 - #73516 (Allow dynamic linking for iOS/tvOS targets)
 - #73616 (Liballoc minor hash import tweak)
 - #73634 (Add UI test for issue 73592)
 - #73688 (Document the self keyword)
 - #73698 (Add procedure for prioritization notifications on Zulip)

Failed merges:

r? @ghost
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.
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 8a77d1c 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 #70517 #40364 #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.

FCP report: #71858 (comment)

Closes #70517
Closes #40364
Closes #44074
A new issue in the cargo repo will be needed to track the cargo side of this feature.

r? @ehuss
@TyPR124 TyPR124 merged commit 00ef461 into TyPR124:master Jun 26, 2020
TyPR124 pushed a commit that referenced this pull request Aug 30, 2021
Otherwise, we can get into a situation where you have
a subtype obligation `#1 <: #2` pending, #1 is constrained
by `check_casts`, but #2` is unaffected.

Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.