This is only changing the names that appear in the JS source and
should not change the runtime semantics. Prepends "_N_" and "_L_"
to nullable and legacy type names.
Function types get their markers prepended to the word "To". For
example a type `int Function(String)` in a legacy library would
have a name in JS like "_L_String_L_To_L_int".
Change-Id: I26416e2c7396806f0ff9b3d36cd915f49d48d1cf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140366
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This is a bare-bones implementation (and test) for having an explicit
toString on all `Node`s.
This can then be extended as-needed to better suit our debugging
purposes. It's not allowed to leak, though.
Change-Id: I8d3f5a9cd13b292ed7a6bf33762e507286f3fa7d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139805
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This is a breaking change. https://github.com/dart-lang/sdk/issues/40709
This change makes the HeaderValue parsing more strict in two invalid
edge cases, supports parameters with null values as a feature, and fixes
toString() so it always produces tokens or quoted-strings valid per RFC
7230 3.2.6.
The empty parameter value without double quotes (which is not allowed by
the standards) is now parsed as the empty string rather than null. E.g.
HeaderValue.parse("v;a=").parameters now gives {"a": ""} rather than
{"a": null}.
Invalid inputs with unbalanced double quotes are now rejected. E.g.
HeaderValue.parse('v;a="b').parameters will now throw a HttpException
instead of giving {"a": "b"}.
The HeaderValue.toString() method now supports parameters with null
values by omitting the value. E.g.:
HeaderValue("v", {"a": null, "b": "c"}).toString()
now gives
v; a; b=c
This behavior can be used to implement some features in the Accept and
Sec-WebSocket-Extensions headers.
Likewise the empty value and values using characters outside of RFC 7230
3.2.6 tokens are now correctly implemented by double quoting such values
with escape sequences. E.g.:
HeaderValue("v",
{"a": "A", "b": "(B)", "c": "", "d": "ø", "e": "\\\""}).toString()
now gives
v;a=A;b="(B)";c="";d="ø";e="\\\""
The NNBD migration required making subtle changes to some dart:io
semantics in order to provide a better API. This change backports one of
these semantic changes to the unmigrated SDK so any issues can be
discovered now instead of blocking the future SDK unfork.
Change-Id: Iafc790e03b6290232cac71fe14f995ce0f0b036b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136620
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
FutureOr<Object> --> Object
FutureOr<Object>? --> Object?
I don't believe this to be breaking because in the current SDK
nullable types do not yet exist, and we already landed the change
to normalize FutureOr of a top type. Right now Object is still
considered a top type.
Issue: #40611
Change-Id: I83cb06db9e4bca8cb9b2c041a044904eb1080d2e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139031
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Unlike non-nullable types, the purpose of the annotation in
our runtime is to ensure we don't generate extra checks. This
should remove a few nullFailed calls in the generated sdk.
Change-Id: I7b8ac012a6cfa5f8baf2667d89185e7540320ec2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138783
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Use a JavaScript Symbol() for Array rti property. This makes the
property non-enumerable, avoiding making the property visible via
JS-interop.
The code is feature-tested so that IE11 still works with an enumerable
String property.
Bug: 40535
Change-Id: Ic8b64dac5751989fe4b8d023b0626c3db04676c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/137245
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This flag is unused and the behavior it enables was only useful along with
`dart:mirrors`.
- Remove the flag and the field on the options object.
- Prune code branches that are no longer reachable.
- Remove or inline some functions that became either empty or trivially small.
- Remove the manual check for a `dart:mirrors` import since this is handled by
the CFE now.
- Remove references to the flag in tests.
- Remove test files which only existed to enable the flag for other tests.
Change-Id: I21bf594271fb4eeb5b73fcbf07da736e9e8d1f33
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138018
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Auto-Submit: Nate Bosch <nbosch@google.com>
Because we cache on instances of type objects, all "type"-ish constructs in DDC must be pre-initialized if we want to avoid any hasOwnProperty checks (which are slow).
1) We now consult legacy/nullable caches earlier when wrapping types, as the downstream logic can be much slower than a lookup.
2) We cache on nullble and legacy wrappers themselves as well as just the underlying object (formerly we cached on just the latter) for faster lookups.
3) We attach local caches upfront, maintaining monomorphicity during hot code paths.
This improves regressions for opt-out worst-case tests from (120 us -> 2100 us) to (120 us -> 500 us) and weak mode tests from (120 us -> 1100 us) to (120 us -> 330 us).
Change-Id: I98a26064404e746162ca3feb22b0993c3b39e63c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138330
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
These changes are also being back ported into the existing SDK
with minimal differences that will be gone when we unfork the
dart:_runtime library. In the current back port:
* FutureOr<Null>? is normalized to Future<Null>* instead of
Future<Null>?.
* There is no runtime normalization of FutureOr<T?>?. This
should have no effect since nullable types can not yet
appear.
Fixes: #40611, #40720
Change-Id: Ib3ddffbf3778f0f571cf95f58b6142d3ee0bf59b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136160
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
New analyzer errors are reported for dart:html around nullability.
Non-nullable fields are translated to native getters and setters if part
of a concrete class and normal getters and setters if abstract.
Change-Id: I2fd87803a08872b2a7eae4de0af704f184997c7e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/137481
Reviewed-by: Stephen Adams <sra@google.com>
The diagnostic applies to both the if-null expression ('??') and the
compound assignment expression ('??='), so it seems like the name should
be more general.
Change-Id: I004cc2924ef97fcbd2168f070380ff17152cbb0f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136903
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
These fixes also prepare for an upcoming change to normalize FutureOr
types.
- Cache and emit the hoisted function type at the top level without
nullability wrappers.
- Always emit nullability wrappers at the use site.
- Fix issue where sometimes the return type would be double wrapped.
Change-Id: If4a0c94e62eca626f271cc3c259c813911075d9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136404
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
CSSStyleDeclaration.getPropertyValue returns a non-nullable string.
It will also return an empty string if the property is not found. Since
getPropertyValue returns the value of the native getPropertyValue, the
null check should be removed.
Change-Id: I9846553d3f9fcd68cbd15b9c39d2104cab594b7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136413
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This is a breaking change. Request: https://github.com/dart-lang/sdk/issues/33501
HttpHeaders use lowercase by default for all headers, since it is supposed to be case insensitive. Some servers incorrectly treat case as significant, however, and expect headers with capitalization or in uppercase. The current implementation forces headers to be lower cases when adding values. Users cannot even manually modify the headers.
This change removes this restriction here so that users can modify the headers to whatever form they want. The new behavior is backwards compatible except if class was implemented. All headers inside http.dart are written as lower cases, adding values to HttpHeaders is still receiving lower cases input.
The other cl (https://dart-review.googlesource.com/c/http_multi_server/+/121411) migrates multi_headers.dart to be compatible with this change.
Bug: https://github.com/dart-lang/sdk/issues/33501
Change-Id: Ieb9f4061b27ed3bbc6d82e6a408c77d11abb037b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135357
Commit-Queue: Zichang Guo <zichangguo@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Nate Bosch