Opened 12 years ago

Closed 11 years ago

#9661 closed enhancement (duplicate)

avoid interning strings when templatePath is commented

Reported by: ben hockey Owned by: James Burke
Priority: high Milestone: future
Component: BuildSystem Version: 1.3.2
Keywords: Cc:
Blocked By: Blocking:


it would be good if we could change the regular expression that interns templatePath to ignore the templatePath if it is commented out (at least for line comments - i realise that block comments might be a lot to expect)

if i was better with regular expressions i would offer the solution and perhaps when i have some time to stop and look at it i'll do just that :)

Change History (5)

comment:1 Changed 12 years ago by Adam Peller

Component: ShrinkSafeBuildSystem
Owner: changed from alex to James Burke

comment:2 Changed 12 years ago by James Burke

Milestone: tbdfuture

Would be good to do for completeness, but as mentioned, block comments would be a problem, and the inlined comment should go away if the file is shrinksafed for performance reasons.

comment:3 in reply to:  2 Changed 12 years ago by ben hockey

Replying to jburke:

inlined comment should go away if the file is shrinksafed for performance reasons.

the comment does go away (of course) but shrinksafe is applied after the build so the build tries to intern the string. i haven't tried to see if i can switch the order. any thoughts on that? i would suspect that it's not possible but i would imagine that if it's possible, it might make the build process faster.

comment:4 Changed 12 years ago by James Burke

Switching the build order would help modules in a layer, since they are more likely to be shrinksafed, but it does not help modules outside a layer. And there is no guarantee that the user wants any shrinksafing at all. So we cannot assume shrinksafing is taking place.

The other problem: if the function itself tries to comment strip code before processing, that probably will not work out since we modify the string by injecting content. It would be nontrivial to track the before and after comment removal test positions and inject the inlining at the right place.

Doing a quick hack to remove code that has a but does not handle block comments might help things, but it also might make things harder to debug for the block comment case ("it skipped the comment over here, but not over here"). But if you think it is more likely that someone has used a line comment, we might be able to do a quick hack for that.

comment:5 Changed 11 years ago by bill

Resolution: duplicate
Status: newclosed

Dup of #2429.

Note: See TracTickets for help on using tickets.