Rollup of 7 pull requests #62580
Merged
Rollup of 7 pull requests #62580
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Because Eq types must be reflexively equal, an equal-length slice to the same memory location must be equal.
The auxiliary file arc_wake.rs is in run-pass/auxiliary and also ui/async-await/auxiliary. Remove the former one as their contents are same. Move run-pass/futures-api.rs to ui/async-await/futures-api.rs as it needs to use arc_wake.rs.
The sizes for wasm are different. Co-Authored-By: Tyler Mandry <tmandry@gmail.com>
All ioctl(2)s will fail on O_PATH file descriptors on Linux (because they use &empty_fops as a security measure against O_PATH descriptors affecting the backing file). As a result, File::try_clone() and various other methods would always fail with -EBADF on O_PATH file descriptors. The solution is to simply use F_SETFD (as is used on other unices) which works on O_PATH descriptors because it operates through the fnctl(2) layer and not through ioctl(2)s. Since this code is usually only used in strange error paths (a broken or ancient kernel), the extra overhead of one syscall shouldn't cause any dramas. Most other systems programming languages also use the fnctl(2) so this brings us in line with them. Fixes: rust-lang#62314 Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
It's internal to resolve and always results in `Res::Err` outside of resolve. Instead put `DefKind::Fn`s themselves into the macro namespace, it's ok. Proc macro stubs are items placed into macro namespase for functions that define proc macros. rust-lang#52383 The rustdoc test is changed because the old test didn't actually reproduce the ICE it was supposed to reproduce.
So it can be eventually used in `ExpnInfo`
More consistent with other naming: ExpnFormat -> ExpnKind ExpnKind::name -> ExpnKind::descr DesugaringKind::name -> DesugaringKind::descr Shorter, no tautology: CompilerDesugaring -> Desugaring CompilerDesugaringKind -> DesugaringKind
The expansions were created to allow unstable things inside `#[test_case/test/bench]`, but that's not a proper way to do that. Put the required `allow_internal_unstable`s into the macros' properties instead.
It was used to choose whether to apply derive markers like `#[rustc_copy_clone_marker]` or not, but it was called before all the data required for resolution is available, so it could work incorrectly in some corner cases (like user-defined derives name `Copy` or `Eq`). Delay the decision about markers until the proper resolution results are available instead.
…osticSpanMacroExpansion We have to deal with dummy spans anyway Remove def-site span from expander interfaces. It's not used by the expansion infra, only by specific expanders, which can keep it themselves if they want it.
Orthogonality and reuse are good.
Avoid the tricky scheme with callbacks and keep the invocation parent data where it logically belongs - in `Definitions`. This also allows to create `InvocationData` entries in resolve when the data is actually ready, and remove cells and "uninitialized" variants from it.
Create real working and registered (even if dummy) `SyntaxExtension`s for them. This improves error recovery and allows to avoid all special cases for proc macro stubs (except for the error on use, of course). The introduced dummy `SyntaxExtension`s can be used for any other inappropriately resolved macros as well.
…ate errors It either returns the indeterminacy error, or valid (but perhaps dummy) `SyntaxExtension`. With this change enum `Determinacy` is no longer used in libsyntax and can be moved to resolve. The regressions in diagnosics are fixed in the next commits.
This way we are processing all of them in a single point, rather than separately for each syntax extension kind. Also, the standard expected/found wording is used.
This is going to be used when built-in macros are defined through libcore and made available to other crates through standard library prelude
…rting parts Also move macro stability checking closer to other checks performed on obtained resolutions. Tighten the stability spans as well, it is an error to *refer* to and unstable entity in any way, not only "call" it.
Ok, it's hard to explain what happens, but identifier's hygienic contexts need to be "adjusted" to modules/scopes before they are resolved in them.
To be resolved in all kinds on preludes the identifier needs to be adjusted to the root expansion (aka "no expansion").
Previously this was done for the `macro m() { ::my_crate::foo }` case, but forgotten for all other cases.
…rkers Create a fresh expansion for them instead - this is the usual way to allow unstable features for generated/desugared code. Fixes rust-lang#52363
Creating a fresh expansion and immediately generating a span from it is the most common scenario. Also avoid allocating `allow_internal_unstable` lists for derive markers repeatedly. And rename `ExpnInfo::with_unstable` to `ExpnInfo::allow_unstable`, seems to be a better fitting name.
Use variant names rather than descriptions for identifying desugarings in `#[rustc_on_unimplemented]`. Both are highly unstable, but variant name is at least a single identifier.
The root expansion was missing one. Expansions created for "derive containers" (see one of the next commits for the description) also didn't get expansion info.
Remove a bunch of `Option`s that assumed that dummy fragment creation could fail. The test output changed due to not performing the expansion in `fn expand_invoc` in case of the recursion limit hit.
It's more convenient to have all this highly related stuff together on one screen (for future refactorings). The `expand_invoc` function is compact enough now, after all the previous refactorings.
…iant
`InvocationKind::Attr { attr: None, .. }` meaning something entirely different from a regular attribute was confusing as hell.
Add a test for the issue resolved by removing `resolve_macro_path` Add a test making sure that extern prelude entries introduced from an opaque macro are not visible anywhere, even it that macro Fix test output after rebase
core: check for pointer equality when comparing Eq slices Because `Eq` types must be reflexively equal, an equal-length slice to the same memory location must be equal. This is related to rust-lang#33892 (and rust-lang#32699) answering this comment from that PR: > Great! One more easy question: why does this optimization not apply in the non-BytewiseEquality implementation directly above? Because slices of non-reflexively equal types (like `f64`) are not equal even if it's the same slice. But if the types are `Eq`, we can use this same-address optimization, which this PR implements. Obviously this changes behavior if types violate the reflexivity condition of `Eq`, because their impls of `PartialEq` will no longer be called per-item, but 🤷♂ . It's not clear how often this optimization comes up in the real world outside of the same-`&str` case covered by rust-lang#33892, so **I'm requesting a perf run** (on MacOS today, so can't run `rustc_perf` myself). I'm going ahead and making the PR on the basis of being surprised things didn't already work this way. This is my first time hacking rust itself, so as a perf sanity check I ran `./x.py bench --stage 0 src/lib{std,alloc}`, but the differences were noisy. To make the existing specialization for `BytewiseEquality` explicit, it's now a supertrait of `Eq + Copy`. `Eq` should be sufficient, but `Copy` was included for clarity.
Prerequisites from dep graph refactoring rust-lang#2 Split out from rust-lang#60035 and overlaps with rust-lang#60559.
…andry Move async-await tests from run-pass to ui fix rust-lang#62236 r? @Centril
…lexcrichton filedesc: don't use ioctl(FIOCLEX) on Linux All `ioctl(2)`s will fail on `O_PATH` file descriptors on Linux (because they use `&empty_fops` as a security measure against `O_PATH` descriptors affecting the backing file). As a result, `File::try_clone()` and various other methods would always fail with `-EBADF` on `O_PATH` file descriptors. The solution is to simply use `F_SETFD` (as is used on other unices) which works on `O_PATH` descriptors because it operates through the `fnctl(2)` layer and not through `ioctl(2)`s. Since this code is usually only used in strange error paths (a broken or ancient kernel), the extra overhead of one syscall shouldn't cause any dramas. Most other systems programming languages also use the fnctl(2) so this brings us in line with them. Fixes: rust-lang#62314 Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Continue refactoring macro expansion and resolution This PR continues the work started in rust-lang#62042. It contains a set of more or less related refactorings with the general goal of making things simpler and more orthogonal. Along the way most of the issues uncovered in rust-lang#62086 are fixed. The PR is better read in per-commit fashion with whitespace changes ignored. I tried to leave some more detailed commit messages describing the motivation behind the individual changes. Fixes rust-lang#44692 Fixes rust-lang#52363 Unblocks rust-lang#62086 r? @matthewjasper
…elix Regression test for HRTB bug (issue 30786). Close rust-lang#30786.
Fix typo in libcore/intrinsics.rs
|
@bors r+ p=7 rollup=never |
|
📌 Commit f9034ce has been approved by |
bors
added
the
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jul 11, 2019
Rollup of 7 pull requests Successful merges: - #61665 (core: check for pointer equality when comparing Eq slices) - #61923 (Prerequisites from dep graph refactoring #2) - #62270 (Move async-await tests from run-pass to ui) - #62425 (filedesc: don't use ioctl(FIOCLEX) on Linux) - #62476 (Continue refactoring macro expansion and resolution) - #62519 (Regression test for HRTB bug (issue 30786).) - #62557 (Fix typo in libcore/intrinsics.rs) Failed merges: r? @ghost
|
☀️ Test successful - checks-azure, checks-travis, status-appveyor |
|
📣 Toolstate changed by #62580! Tested on commit 6907005. 💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk @phansch, @rust-lang/infra). |
rust-highfive
added a commit
to rust-lang-nursery/rust-toolstate
that referenced
this pull request
Jul 11, 2019
Tested on commit rust-lang/rust@6907005. Direct link to PR: <rust-lang/rust#62580> 💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk @phansch, @rust-lang/infra). 💔 clippy-driver on linux: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk @phansch, @rust-lang/infra).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Failed merges:
r? @ghost