Single-File: Process bundles in the framework #34274

swaroop-sridhar · 2020-03-30T09:32:23Z

This change implements the host changes proposed in the design

The main changes for single-file bundles are:

Bundle processing code is moved from apphost to hostpolicy
HostFxr and HostPolicy process deps.json and runtimeconfig.json files directly from the bundle.
HostPolicy performs verification wrt deps.json based on the contents of the single-file bundle.
AppContext.BaseDirectory is set as explained here

Currently, all files except deps.json and runtimeconfig.json are extracted to disk.
Once the runtime is able to processing assemblies directly from the bundle, they will no longer be extracted.

Notable details:

The bundle driver (formarly runner.cpp) is divided into two parts:
- bundle::info which describes basic information about the bundle available from the headers only
- bundle::runner which has information about all embedded files, and the ability to drive extraction
  This facilitates linking only parts of the bundle handling code with hostfxr, while all code is linked with hostpolicy.
The AppHost only links with bundle_marker to identify itself as a single-file bundle.
If the AppHost is a single-file bundle, it notifies hostfxr using the new hostfxr_main_bundle_startup_info() API
The HostFxr comminucates the single-file-information with HostPolicy using the host_interface_t structure.

Fixes #32821

lpereira · 2020-04-01T17:13:25Z

src/installer/corehost/cli/json/rapidjson/cursorstreamwrapper.h

@@ -46,7 +46,7 @@ class CursorStreamWrapper : public GenericStreamWrapper<InputStream, Encoding> {
    // counting line and column number
    Ch Take() {
        Ch ch = this->is_.Take();
-        if(ch == '\n') {
+        if (ch == '\n') {


This is a harmless change, but I'd prefer if rapidjson were kept as a pristine copy from upstream, as it's a 3rd-party component. (If we need to actually fix things in there, I'd prefer that we also sent patches their way instead of maintaining a fork.)

OK @lpereira I'll back off the change from this PR.
I've submitted a PR for rapidjson: Tencent/rapidjson#1685
We should subsequently fix it in our code too.
I usually do if( for( while( searches before submitting PRs, and it would be nice to not hit these cases every time.

lpereira · 2020-04-01T17:23:47Z

src/installer/corehost/cli/json_parser.cpp

+            realloc_buffer(location->size);
+            memcpy(m_json.data(), data, location->size);


I usually see the idiom of using the swap() method to initialize a std::vector from an array, so I was curious to see how Clang would generate the code. It's identical. I'm impressed. :)

However, you can avoid this copy/allocation altogether here if this file is mapped with MAP_PRIVATE. In fact, this will simplify how this function works, since it won't need the #ifdef. Pseudocode:

if (is_single_file) { bundled_file_t bundled{path, location}; // RAII to map/unmap return parse_json(bundled.data(), context); } pal::ifstream_t file{path}; return parse_stream(file, path);

Then you don't need to split parse_json() into a parse/validate combo, and parse_json() can always work with a mutable char*. This also gets rid of duplicate, implementation-detail specific comments.

lpereira · 2020-04-01T17:34:30Z

src/installer/corehost/cli/json_parser.cpp

+            // On Linux, copy the input data, since m_document.ParseInsitu
+            // requires a mutable data input.


Suggested change

// On Linux, copy the input data, since m_document.ParseInsitu

// requires a mutable data input.

// On other platforms, copy the input data, since m_document.ParseInsitu

// requires a mutable data input.

lpereira · 2020-04-01T17:36:23Z

src/installer/corehost/cli/runtime_config.cpp

@@ -398,13 +401,13 @@ bool runtime_config_t::ensure_parsed()
        trace::verbose(_X("Did not successfully parse the runtimeconfig.dev.json"));
    }

-    if (!pal::file_exists(m_path))
+    json_parser_t json;


Suggested change

json_parser_t json;

lpereira · 2020-04-01T17:36:43Z

src/installer/corehost/cli/runtime_config.cpp

    {
        // Not existing is not an error.
        return true;
    }

-    json_parser_t json;


Suggestion:

Suggested change

json_parser_t json;

json_parser_t json;

lpereira · 2020-04-01T21:05:58Z

src/installer/corehost/cli/bundle/info.cpp

+    // * Files can only be memory mapped at page-aligned offsets, and in whole page units.
+    //   Therefore, mapping only portions of the bundle will involve align-down/round-up calculations, and associated offset adjustments.
+    //   We choose the simpler approach of rounding to the whole file


Might be a good idea to comment that this might be a problem in 32-bit systems and very large applications due to exhaustion of address space.

lpereira · 2020-04-01T21:09:43Z

src/installer/corehost/cli/bundle/info.h

+        private:
+            pal::string_t m_path;
+            const location_t *m_location;
+        } json_info;


json_info doesn't seem to be used from a quick glance.

lpereira · 2020-04-01T21:12:25Z

src/installer/corehost/cli/bundle/info.h

+    {
+        struct config_t
+        {
+            config_t() {}


This doesn't initialize m_location, and config_t::matches() will dereference that pointer. When info_t::m_deps_jsonand info_t::m_runtimeconfig_json are constructed, they use this constructor here.

lpereira · 2020-04-01T21:17:59Z

src/installer/corehost/cli/bundle/manifest.cpp

@@ -12,7 +12,9 @@ manifest_t manifest_t::read(reader_t& reader, int32_t num_files)

    for (int32_t i = 0; i < num_files; i++)
    {
-        manifest.files.emplace_back(file_entry_t::read(reader));
+        file_entry_t entry = file_entry_t::read(reader);
+        manifest.files.emplace_back(entry);


Nit: Is there a benefit for using emplace_back()here? Maybe file_entry_t should have a move constructor and std::movebe used instead?

lpereira · 2020-04-01T21:26:08Z

src/installer/corehost/cli/bundle/info.cpp

+const int8_t* info_t::config_t::map(const pal::string_t& path, const location_t* &location)
+{
+    const bundle::info_t* app = bundle::info_t::the_app;
+


Since the_app is static and initialized to nullptr, might be a good idea to assert if it's not nullptr where it's dereferenced

lpereira · 2020-04-01T21:29:29Z

src/installer/corehost/cli/bundle/runner.cpp

+    pal::string_t file_base = entry->needs_extraction() ? app->extraction_path() : app->base_path();
+
+    // Reserve space for the path below
+    full_path.reserve(file_base.length() + relative_path.length() + 3);


What's the 3 for?

This is code copied from https://github.com/dotnet/runtime/blob/master/src/installer/corehost/cli/deps_entry.cpp#L32.
Two characters are required for DIR_SEPARATOR and null-terminator. Not sure why the third spot is necessary.

lpereira · 2020-04-01T21:30:56Z

src/installer/corehost/cli/deps_entry.cpp

+    pal::string_t pal_relative_path = asset.relative_path;
+    if (_X('/') != DIR_SEPARATOR)
+    {
+        replace_char(&pal_relative_path, _X('/'), DIR_SEPARATOR);
+    }


Suggested change

pal::string_t pal_relative_path = asset.relative_path;

if (_X('/') != DIR_SEPARATOR)

{

replace_char(&pal_relative_path, _X('/'), DIR_SEPARATOR);

}

pal::string_t pal_relative_path = normalize_dir_separator(asset.relative_path);

src/installer/corehost/cli/hostmisc/pal.unix.cpp

lpereira · 2020-04-01T21:36:30Z

src/installer/corehost/cli/hostmisc/pal.unix.cpp


-    if(address == nullptr)
+    if (address == nullptr)


Suggested change

if (address == nullptr)

close(fd);

if (address == MAP_FAILED)

lpereira · 2020-04-01T21:37:03Z

src/installer/corehost/cli/hostmisc/pal.unix.cpp


-    if(address == nullptr)
+    if (address == nullptr)
    {
        trace::error(_X("Failed to map file. mmap(%s) failed with error %d"), path.c_str(), errno);
        close(fd);


Suggested change

close(fd);

(And also remove the other close(fd)below, which GitHub doesn't allow me to comment on.)

lpereira · 2020-04-01T21:53:25Z

src/installer/corehost/cli/hostpolicy/hostpolicy_init.cpp

+    {
+        if (input->app_bundle != nullptr)
+        {
+            static bundle::runner_t bundle_runner(input->app_bundle);


I keep reading this as Blade Runner. :)

swaroop-sridhar · 2020-04-02T01:46:27Z

src/installer/corehost/cli/json/rapidjson/document.h

@@ -2094,11 +2094,11 @@ class GenericValue {

        const SizeType len1 = GetStringLength();
        const SizeType len2 = rhs.GetStringLength();
-        if(len1 != len2) { return false; }
+        if (len1 != len2) { return false; }


https://github.com/dotnet/runtime/pull/34274/files/51c0c31d0a9cb26a6e3119bf6609cd300c90c96c#r402006698

vitek-karas

I have yet to look at tests. The most important feedback is about the UX when we run 5.0 single-file on machine which doesn't have 5.0. We need to get that right.

src/installer/corehost/cli/fxr/hostfxr.cpp

vitek-karas · 2020-04-02T10:23:24Z

src/installer/corehost/cli/fxr/hostpolicy_resolver.cpp

@@ -238,7 +238,8 @@ bool hostpolicy_resolver::try_get_dir(

    // Resolve hostpolicy version out of the deps file.
    pal::string_t version = resolve_hostpolicy_version_from_deps(resolved_deps);
-    if (trace::is_enabled() && version.empty() && pal::file_exists(resolved_deps))
+    if (trace::is_enabled() && version.empty() &&
+        (bundle::info_t::config_t::probe(resolved_deps)|| pal::file_exists(resolved_deps)))


Suggested change

(bundle::info_t::config_t::probe(resolved_deps)|| pal::file_exists(resolved_deps)))

(bundle::info_t::config_t::probe(resolved_deps) || pal::file_exists(resolved_deps)))

src/installer/corehost/cli/fxr/hostpolicy_resolver.cpp

vitek-karas · 2020-04-02T11:13:02Z

src/installer/corehost/cli/hostpolicy/deps_resolver.cpp

@@ -343,6 +343,12 @@ bool deps_resolver_t::probe_deps_entry(const deps_entry_t& entry, const pal::str
                else
                {
                    // Non-rid assets, lookup in the published dir.


I assume we only handle bundle for non-rid assets as we expect the app to be rid-specific (since it's an apphost after all). But I think this is potentially dangerous. For framework depend apps it is in theory possible to have an app which is published for linux-x64 but carries different assets for different distros. I don't know how SDK would handle that, but it feels possible. At least add this scenario to your list of things to validate.
I would probably also prefer if we actually checked the path even in the rid-specific case above and maybe failed if we can't handle it.

@vitek-karas, regarding rid-specific assets:

I've added the bundle-check in the rid-specific assets case too, as you've recommended.

However, when an app is published specific to a RID, my understanding is that the SDK will never create assets for other RIDs. The SDK will find the best compatible RID assets and copy them to the publish directory. So, there won't be a <rid>\publish\runtimes\<rid> structure.

For example, if we have a package (libuv 1.9.0 is a very good example)

runtimes |- debian-x64/native/lib.so |- rhel-x64/native/lib.so |- win-x64/native/lib.dll

dotnet publish will generate the above directory structure within the bin/.net5/publish directory.

However, dotnet publish -r debian-x64 --self-contained=false will generate bin/.net5/debian-x64/publish that only contains lib.so from runtime/debian-x64/native.

dotnet publish -r ubuntu-x64 --self-contained=false will generate bin/.net5/ubuntu-x64/publish that contains lib.so from runtime/debian-x64/native.

dotnet publish -r linux-x64 --self-contained=false will generate bin/.net5/linux-x64/publish without lib.so

dotnet publish -r linux-x64 --self-contained=false will generate bin/.net5/linux-x64/publish without lib.so

This sounds like a problem/bug. I assume the app would not run in that case at all... right?

I agree that there is an underlying problem, because the app may fail to run because of missing assemblies in this situation. However, I'm not sure it is an SDK bug, but rather a product issue.

The missing RID-asset (here linux-x64) in a package may actually mean that the library (lib.so) is unnecessary for that platform -- although it is weird that the lib is not necessary at a higher RID but necessary in a lower RID. This is somewhat similar to missing an assembly that is only loaded at runtime for reflection -- where the SDK cannot know the exact requirements.

@dsplaisted @wli3: Should we consider guards in the SDK to check for this case? (ex: missing assets at a parent RID)? Thanks.

@swaroop-sridhar I have a feeling trying to add guards for this type of thing would be more complex and complicated than would be warranted for the benefit we would get out of it. But you can file an issue in the SDK repo if you want to discuss it further.

dotnet/sdk#11206

src/installer/corehost/cli/bundle/info.cpp

src/installer/corehost/corehost.cpp

This change implements the host changes proposed in the [design](https://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md#startup) The main changes for single-file bundles are: * Bundle processing code is moved from apphost to hostpolicy * HostFxr and HostPolicy process deps.json and runtimeconfig.json files directly from the bundle. * HostPolicy performs verification wrt deps.json based on the contents of the single-file bundle. * AppContext.BaseDirectory is set as explained [here](https://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md#appcontextbasedirectory) Currently, all files except deps.json and runtimeconfig.json are extracted to disk. Once the runtime is able to processing assemblies directly from the bundle, they will no longer be extracted. Notable details: * The bundle driver (formarly runner.cpp) is divided into two parts: * bundle::info which describes basic information about the bundle available from the headers only * bundle::runner which has information about all embedded files, and the ability to drive extraction This facilitates linking only parts of the bundle handling code with hostfxr, while all code is linked with hostpolicy. * The AppHost only links with bundle_marker to identify itself as a single-file bundle. * If the AppHost is a single-file bundle, it notifies hostfxr using the new hostfxr_main_bundle_startup_info() API * The HostFxr comminucates the single-file-information with HostPolicy using the host_interface_t structure. Fixes dotnet#32821

The rename test would hang forever if AppWithWait() fails before creating the resume file. So, while waiting, check that the app-process is still running.

* Fix HostFxr startup function naming in CoreHost * deps_resolver: Lookup up bundle even for rid-specific assets within the app * Ensure CUI/GUI error output when expected framework is not found for single file apps. * Other minor fixes

src/installer/corehost/corehost.cpp

vitek-karas

I think I 'm struggling to understand what is the hostpolicy/coreclr interface. In the design doc https://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md#dependency-resolution it says:

The assemblies bundled within the single-file are not enumerated in TRUSTED_PLATFORM_ASSEMBLIES. The absolute-path of assemblies on disk are listed in TRUSTED_PLATFORM_ASSEMBLIES as usual.

But if I read the code correctly it will populate TPA with full paths even for bundled assemblies - relative to the app's base.

Similar comment on resource paths.

src/installer/corehost/cli/deps_entry.cpp

src/installer/corehost/cli/bundle/runner.cpp

src/installer/corehost/cli/deps_entry.cpp

src/installer/test/Assets/TestProjects/AppWithSubDirs/Program.cs

swaroop-sridhar · 2020-04-06T20:30:46Z

I think I 'm struggling to understand what is the hostpolicy/coreclr interface. In the design doc https://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md#dependency-resolution it says:

The assemblies bundled within the single-file are not enumerated in TRUSTED_PLATFORM_ASSEMBLIES. The absolute-path of assemblies on disk are listed in TRUSTED_PLATFORM_ASSEMBLIES as usual.

But if I read the code correctly it will populate TPA with full paths even for bundled assemblies - relative to the app's base.

Similar comment on resource paths.

There is a small nuance to this:

The assmeblies bundled into the single-file, that are not extracted to disk are not entered to the TPA (since there is no associated path "real" path). The runtime will know to probe for these assemblies and then load them directly from bundle.
The assemblies on disk (whether extracted to disk or left on disk) will remain on the TPA as usual.
We do not anticipate having to extract assemblies to disk once the runtime is able to process assemblies from bundle. So, the design doesn't explicitly mention this.
We could (depending on feedback) extract assemblies to disk in netcoreapp3.0 compatibility mode.

Also update a few comments to clarify that assemblies are currently extracted to disk.

elinor-fung · 2020-04-07T02:10:01Z

src/installer/corehost/cli/host_interface.h

@@ -58,6 +59,7 @@ struct host_interface_t
    const pal::char_t* host_info_host_path;
    const pal::char_t* host_info_dotnet_root;
    const pal::char_t* host_info_app_path;
+    const bundle::info_t *app_bundle;


bundle::info_t does not look to be plain data, so using it cross-binary like this where hostpolicy reads the class allocated by hostfxr could lead to compat issues.

Thanks @elinor-fung . I've fixed this in 12b63ba

elinor-fung · 2020-04-07T02:11:42Z

src/installer/corehost/cli/fxr/hostpolicy_resolver.cpp

@@ -12,6 +12,7 @@
 #include <utils.h>

 #include "json_parser.h"
+#include "bundle/info.h"


Not needed?

vitek-karas

Looks good - the one pending question I have is the RID specific asset handling.

Host::info* is not POD, so pass the bundle-header offset instead. The deps-json and runtime-config json locations are recomputed in hostpolicy. Since hostpolicy needs to re-map the bundle, recomputing these locations is not expensive than passing them through the interface. This also keeps the host_interface cleaner.

swaroop-sridhar · 2020-04-08T05:28:03Z

Looks good

Thanks a lot for the detailed feedback @vitek-karas
I have a few minor fixes in the last couple of commits. It'd be great if you can take a look at these too.

the one pending question I have is the RID specific asset handling.

I've now answered this in #34274 (comment)

vitek-karas

Looks good.

Please followup on the issue with RID-specific assets. I do agree that vast majority of the apps won't have the problem. If SDK will never add a RID-specific asset to a RID-specific build, then this is not an issue for host/runtime (yet), but it seems to be an SDK issue.

…sing extraction Customer Scenario Self-contained Apps published as a single-file fail at run-time. Problem Single-file bundles are now processed in the framework rather than the apphost (dotnet/runtime#34274). This means that hostpolicy and hostfxr DLLs are excluded from being bundled themselves. In the case of self-contained single-file apps, these files need to be separate files until static-apphost is available. This needs to be ensured by the SDK; otherwise app execution will fail. Solution This change fixes the problem by adapting the SDK to: * Pass the correct target-OS settings (otherwise cross-targetting builds will not work correctly) * Copy files excluded by the Bundler to the publish directory. The stage-0 netcoreapp is updated to preview4, because preview2 apphost is not compatible with preview4 bundler. Risk Low

This commit reverts: Revert "Single-File: Process bundles in the framework (dotnet#34274)" This reverts commit 78b303d. Revert "Single-File Bundler: Add a FileSize test (dotnet#35149)" This reverts commit 779588a.

This commit reverts: Revert "Single-File: Process bundles in the framework (#34274)" This reverts commit 78b303d. Revert "Single-File Bundler: Add a FileSize test (#35149)" This reverts commit 779588a. *Customer Scenario* Publishing apps as a self-contained single-file doesn't work as expected. * Publish needs to generate hostpolicy and hostfxr separate from the single file bundle * Cross-platform publishing is incorrect *Problem* Since Static-apphost is not yet ready, processing bundle content in hostpolicy means that hostpolicy and hostfxr DLLs need to be separate from the bundle. This causes self-contained single-file apps to not be a "single file" temporarily. The change also requires supporting changes from the SDK, to publish hostfxr and hostpolicy as separate files, and to invoke HostModel library with arguments that facilitate cross-platform publishing. *Solution* To solve these, problem, this change reverts: Revert "Single-File: Process bundles in the framework (#34274)" commit 78b303d. and a dependent test-only change: Revert "Single-File Bundler: Add a FileSize test (#35149)" commit 779588a. *Risk* Medium The change is contained to only host components: apphost, hostpolicy, and hostfxr. However, the change is big, and needs testing in runtime and SDK repos. *Testing* Manually tested the SDK by inserting apphost, hostfxr, hostpolicy, and hostmodel library from this build into the `dotnet/packs` preview-4 SDK from dotnet/sdk#11518 build. Verified that: * Singlefile apps can be published and run OK for { Windows, Linux, Osx } x {netcoreapp3.0, netcoreapp3.1, netcoreapp5.0} * Cross-targeting builds of single-file apps build and run OK (ex: built on Windos, run on Mac).

Dotnet-GitSync-Bot added the area-Host label Mar 30, 2020

swaroop-sridhar added area-Single-File and removed area-Host labels Mar 30, 2020

swaroop-sridhar requested review from lpereira and vitek-karas April 1, 2020 07:23

lpereira reviewed Apr 1, 2020

View reviewed changes

src/installer/corehost/cli/hostmisc/pal.unix.cpp Show resolved Hide resolved

lpereira reviewed Apr 1, 2020

View reviewed changes

swaroop-sridhar commented Apr 2, 2020

View reviewed changes

vitek-karas requested changes Apr 2, 2020

View reviewed changes

swaroop-sridhar and others added 9 commits April 4, 2020 00:00

Fix tests

3e3ae6d

Tests: Publish files excluded from bundle to bundle directory

9982baa

Fix a few test leg failures

3ef4372

Address feedback from @lpereira

b6d2786

Undo temporary test changes

b71feee

Fix a rename bug

090daf0

Improve a test

5c32152

The rename test would hang forever if AppWithWait() fails before creating the resume file. So, while waiting, check that the app-process is still running.

Address feedback from vitek-karas

e8703c3

* Fix HostFxr startup function naming in CoreHost * deps_resolver: Lookup up bundle even for rid-specific assets within the app * Ensure CUI/GUI error output when expected framework is not found for single file apps. * Other minor fixes

Fix a non-apphost scenario

1a86437

vitek-karas reviewed Apr 5, 2020

View reviewed changes

src/installer/corehost/corehost.cpp Outdated Show resolved Hide resolved

swaroop-sridhar added 2 commits April 5, 2020 14:51

Fix a bug in deps resolution

4f60411

Fix resource path

755b27a

vitek-karas reviewed Apr 6, 2020

View reviewed changes

Add apphost version to framework_missing URL

ff561f6

Also update a few comments to clarify that assemblies are currently extracted to disk.

elinor-fung reviewed Apr 7, 2020

View reviewed changes

Fix a bug in hostpolicy initialization for nativehost

3268b29

swaroop-sridhar force-pushed the json branch from 68a2a78 to 3268b29 Compare April 7, 2020 07:23

vitek-karas approved these changes Apr 7, 2020

View reviewed changes

swaroop-sridhar force-pushed the json branch from 12b63ba to 7d2c74e Compare April 7, 2020 21:22

Fix an mmap() call

6fdc843

Fix json_parser: Unmap only during destruction.

9aaffc4

vitek-karas approved these changes Apr 8, 2020

View reviewed changes

riarenas mentioned this pull request Apr 8, 2020

Failures to restore from Azure artifacts feeds due to throttling dotnet/arcade#4190

Closed

swaroop-sridhar merged commit 78b303d into dotnet:master Apr 8, 2020

This was referenced Apr 30, 2020

[release/5.0.1xx-preview4] Single-File: Fix GenerateBundle Task dotnet/sdk#11502

Closed

[release/5.0-preview4] Single-File: Fix a json parsing issue #35656

Closed

swaroop-sridhar mentioned this pull request Apr 30, 2020

[release/5.0-preview4] Revert processing bundles in framework #35679

Merged

swaroop-sridhar mentioned this pull request May 16, 2020

Support Single-File Apps in .NET 5 #36590

Closed

30 tasks

ghost locked as resolved and limited conversation to collaborators Dec 10, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Single-File: Process bundles in the framework #34274

Single-File: Process bundles in the framework #34274

swaroop-sridhar commented Mar 30, 2020

lpereira Apr 1, 2020

swaroop-sridhar Apr 2, 2020

lpereira Apr 1, 2020 •

edited

Loading

lpereira Apr 1, 2020

lpereira Apr 1, 2020

lpereira Apr 1, 2020

lpereira Apr 1, 2020

lpereira Apr 1, 2020 •

edited

Loading

lpereira Apr 1, 2020

lpereira Apr 1, 2020

lpereira Apr 1, 2020

lpereira Apr 1, 2020

swaroop-sridhar Apr 2, 2020

lpereira Apr 1, 2020 •

edited

Loading

lpereira Apr 1, 2020 •

edited

Loading

lpereira Apr 1, 2020 •

edited

Loading

lpereira Apr 1, 2020

swaroop-sridhar Apr 2, 2020

vitek-karas left a comment

vitek-karas Apr 2, 2020

vitek-karas Apr 2, 2020

swaroop-sridhar Apr 8, 2020

vitek-karas Apr 8, 2020

swaroop-sridhar Apr 8, 2020

dsplaisted Apr 8, 2020

swaroop-sridhar Apr 8, 2020

vitek-karas left a comment

swaroop-sridhar commented Apr 6, 2020

elinor-fung Apr 7, 2020

swaroop-sridhar Apr 7, 2020

elinor-fung Apr 7, 2020

vitek-karas left a comment

swaroop-sridhar commented Apr 8, 2020 •

edited

Loading

vitek-karas left a comment

		realloc_buffer(location->size);
		memcpy(m_json.data(), data, location->size);

		// On Linux, copy the input data, since m_document.ParseInsitu
		// requires a mutable data input.

	(bundle::info_t::config_t::probe(resolved_deps)\|\| pal::file_exists(resolved_deps)))
	(bundle::info_t::config_t::probe(resolved_deps) \|\| pal::file_exists(resolved_deps)))

Single-File: Process bundles in the framework #34274

Single-File: Process bundles in the framework #34274

Conversation

swaroop-sridhar commented Mar 30, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lpereira Apr 1, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lpereira Apr 1, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lpereira Apr 1, 2020 • edited Loading

Choose a reason for hiding this comment

lpereira Apr 1, 2020 • edited Loading

Choose a reason for hiding this comment

lpereira Apr 1, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vitek-karas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vitek-karas left a comment

Choose a reason for hiding this comment

swaroop-sridhar commented Apr 6, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vitek-karas left a comment

Choose a reason for hiding this comment

swaroop-sridhar commented Apr 8, 2020 • edited Loading

vitek-karas left a comment

Choose a reason for hiding this comment

lpereira Apr 1, 2020 •

edited

Loading

lpereira Apr 1, 2020 •

edited

Loading

lpereira Apr 1, 2020 •

edited

Loading

lpereira Apr 1, 2020 •

edited

Loading

lpereira Apr 1, 2020 •

edited

Loading

swaroop-sridhar commented Apr 8, 2020 •

edited

Loading