Always allow tensor metadata change #83545
Closed
Conversation
This file contains hidden or 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
This PR is to flush out test failures. We will then remove the logic in subsequent PRs. Signed-off-by: Edward Z. Yang <ezyang@fb.com> [ghstack-poisoned]
🔗 Helpful links
❌ 6 New FailuresAs of commit 0d42912 (more details on the Dr. CI page): Expand to see more
🕵️ 6 new failures recognized by patternsThe following CI failures do not appear to be due to upstream breakages
|
This PR is to flush out test failures. We will then remove the logic in subsequent PRs. Signed-off-by: Edward Z. Yang <ezyangfb.com> [ghstack-poisoned]
|
@bdhirsh is going to grind through the rest of the test failures |
bdhirsh
added a commit
that referenced
this pull request
Aug 17, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). [ghstack-poisoned]
bdhirsh
added a commit
that referenced
this pull request
Aug 17, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). [ghstack-poisoned]
bdhirsh
added a commit
that referenced
this pull request
Aug 18, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). [ghstack-poisoned]
bdhirsh
added a commit
that referenced
this pull request
Aug 18, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). [ghstack-poisoned]
bdhirsh
added a commit
that referenced
this pull request
Aug 18, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). [ghstack-poisoned]
bdhirsh
added a commit
that referenced
this pull request
Aug 18, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). [ghstack-poisoned]
bdhirsh
added a commit
that referenced
this pull request
Aug 19, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). [ghstack-poisoned]
bdhirsh
added a commit
that referenced
this pull request
Aug 19, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). [ghstack-poisoned]
bdhirsh
added a commit
that referenced
this pull request
Aug 19, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). [ghstack-poisoned]
bdhirsh
added a commit
that referenced
this pull request
Aug 19, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). [ghstack-poisoned]
pytorchmergebot
pushed a commit
that referenced
this pull request
Aug 19, 2022
Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc @albanD @ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). Pull Request resolved: #83590 Approved by: https://github.com/ezyang
facebook-github-bot
pushed a commit
that referenced
this pull request
Aug 23, 2022
Summary: Make it so that it is valid to set metadata after detach calls, like `x.detach().resize_(...)`. This technically lifts some restrictions around `.data`. This PR means that you can now technically call `x.data.resize_(...)`, which can now directly resize `x` instead of erroring. My understanding: Before the tensor-variable merge, when `x` and `x.data` were really different tensors, you could resize `x.data` independently of `x`, and during the merge, this error was added to avoid silent confusing behavior changes. It was agreed that this error has been around long enough (several years) that it's acceptable to drop. cc albanD ezyang. (Ed already had a prototype PR [here](#83545) - I ended up making one to try to slog through test failures). Pull Request resolved: #83590 Approved by: https://github.com/ezyang Test Plan: contbuild & OSS CI, see https://hud.pytorch.org/commit/pytorch/pytorch/0c24af498578480547822bce5c3aa43a6fa8b920 Reviewed By: seemethere Differential Revision: D38910832 Pulled By: bdhirsh fbshipit-source-id: 85cdbda9825547b35ec5d09f7ff3ca4c2b6996c3
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Stack from ghstack (oldest at bottom):
This PR is to flush out test failures. We will then remove the
logic in subsequent PRs.
Signed-off-by: Edward Z. Yang ezyang@fb.com