Complete 2.14 dynamo release notes

[anijain2305]

Categorizes the 258 PRs in the dynamo worksheet, plus #187088 pulled in from miscategorized.md and #192003 pulled in from the skip worksheet (a user-facing nested_compile_region capability that its author had labeled not-user-facing). Every PR appears exactly once and Untopiced is empty.

Review order: bc breaking (the tvm relay removal) and deprecation (enable_faithful_generator_behavior) carry the before/after examples, then new features, then the long improvements and bug fixes sections. Bullets in those two sections are ordered in thematic blocks rather than by PR number - nested_compile_region first, then torch API coverage / guards and precompile, Python semantics, version-specific fixes, and backends - since the category set is fixed and ordering is the only grouping the merge script allows.

Test Plan: no code in this repo, so verification was a coverage check over the finished worksheet:

python3 -c "
import re; from collections import Counter
t = open('2.14.0/done/result_dynamo.md').read().split('## dynamo')[1]
p = re.findall(r'/pull/(\d+)', t)
print(len(p), len(set(p)), [k for k,c in Counter(p).items() if c>1])"

260 links, 260 unique, no duplicates, all 11 category headings present.

Categorization used commit messages and diffs from a local pytorch checkout (git show) rather than the gh label queries the worksheet instructions suggest, because api.github.com is not reachable from this environment. Labels were therefore unavailable, so no PRs were moved out to miscategorized.md.

Authored with assistance from Claude Code.

[amjames]

@anijain2305 I was preparing this myself and noted the major difference between the result I have locally and this is the omission of two bullet points from the Bc breaking section:

They both seem to be of the form where dynamo previously accepted behavior it should not have and that has now been fixed. I suppose an argument could be made for these not actually being BC breaking

• next() on a non-iterator now raises TypeError under torch.compile instead of silently returning the first element (#190624)

  Dynamo's next() handling skipped CPython's iterator check and, for a list, returned its first item instead of raising. Compiled code that relied on this accidental behavior now sees the same TypeError: '<type>' object is not an iterator that eager Python raises. Wrap the argument in iter() to get the old result.

  Version 2.13:

  >>> @torch.compile(fullgraph=True)
  ... def f(xs):
  ...     return next(xs)
  >>> f([1, 2, 3])
  1

  Version 2.14:

  >>> f([1, 2, 3])
  TypeError: 'list' object is not an iterator
  
  >>> # workaround: match eager semantics explicitly
  >>> @torch.compile(fullgraph=True)
  ... def f(xs):
  ...     return next(iter(xs))
  >>> f([1, 2, 3])
  1

• set() and frozenset() now reject keyword arguments under torch.compile (#189051)

  set(a=1) and set().__init__(a=1) silently produced an empty set inside a compiled region because the keyword check ran only after a zero-positional-argument early return. Dynamo now raises TypeError: set() takes no keyword arguments (and the frozenset() equivalent), matching CPython. Code that passed keywords was already a bug in eager; drop the keyword arguments.

  Version 2.13:

  >>> @torch.compile(fullgraph=True)
  ... def f():
  ...     return set(a=1)
  >>> f()
  set()

  Version 2.14:

  >>> f()
  TypeError: set() takes no keyword arguments

[anijain2305]

@amjames please feel free to take over. You can open a new PR, i can close this one , or you can just modify this PR. Let me know.

[anijain2305]

Also the two bullets you mentioned does not seem like BC, they seem like pre-existing bugs that we have fixed. So they land in bug fixes or improvements.